On 07/21/2019 01:46 PM, Bruce Dubbs via blfs-dev wrote:
On 7/20/19 9:21 PM, Ken Moffat via blfs-dev wrote:On Sun, Jul 21, 2019 at 11:29:51AM +1000, Wayne Blaszczyk wrote:On Sat, 2019-07-20 at 18:02 +0100, Ken Moffat via blfs-dev wrote:On Sat, Jul 20, 2019 at 09:01:00AM -0400, Jean-Marc Pigeon via blfs-dev wrote:Solution is to add #include <linux/sockios.h> within qt-everywhere-src-5.13.0/qtserialbus/src/plugins/canbus/socketcan/socketcanbackend.cpp Hoping this help. (I guess the qt-5.13.0-upstream_fixes-1.patch, need to be slightly updated :) ).Sounds as if this is more widespread :-( https://lore.kernel.org/lkml/20190720174844.4b989d34@sf/T/#u At a minimum, firefox, qemu, and something called linux-atm.The problem appears to be caused by a change in a linux header. I am reluctant to include a long header for what is basically a devinition of a constant. For a temporary workaround in qt/qtwebengine we can use: sed -i 's/SIOCGSTAMP/0x8906/' \ qtserialbus/src/plugins/canbus/socketcan/socketcanbackend.cpp \ qtwebengine/src/3rdparty/chromium/net/base/network_interfaces_linux.cc I don't really like this, but I like including a linux/ header even less. This is currently being tested, so I'm not 100% sure it will work. We can probably do the same for firefox and qemu. I don't know about thunderbird or other packages. It is unfortunate that these required changes all affect very large packages. -- Bruce
My 2 cents: Setting SIOCGSTAMP/0x8906 is "pure evil", I'll explain why later bellow. First: Let see the QT problem from the layering stand point (My mantra :) ) Qt is a package high enough within the software tool-chain, it should be OS unaware. OS dependencies should be hidden somewhere within a QT include (lets say qtos.h, and missing definition detected within the qtos.h) OR (better) use an Interface library to make QT working on different OS by hiding the socket intrinsic. My "fix" proposal was very short sighted, my only goal was to have my (near) 600 packages to be recompiled "without flow" within the 3 hours mark. From BLSF stand point all modification/patch are small local adjustment/trick to have it working, the way the upstream will carry (or not) the modification, is the upstream privilege. But.. BLSF, other mission, (beside building from scratch) could be to provide feedback to upstream, and lets them know they are not "OS Blind"... as soon OS Team is adjusting itscode definition (and this is the OS team privilege) QT is in trouble, please work out your layering!.
Now.... SIOCGSTAMP/0x8906 adjustment proposal not only keep the OS dependency within QT. but introduce hardware dependency too. Which from the layering stand point is "pure evil" :) . Just sharing few ideas... No layering! We're doomed! Dooomed!
That was only posted a few minutes ago, will be interesting to see what is advised so that applications can build against old and new headers. The link for linux-atm looks like a good fix (include inux/sockios.h if SIOCGSTAMP is not defined), but I suggest waiting for comments from our 'betters' because this almost looks like userspace breakage ;-)I've come across this issue with the dnsmasq package: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function and possible indirectly related, the libvirt-python package. Both are not in BLFS.Earlier, I tried to reply to an lkml post about this, suggesting that it seemed to be a regression. But gmail (my normal address is barred because I resubscribed after my upstream randomly rejected some mails, as it does) fooled me into top-posting and sending multipart html, so the message got explicitly rejected by some of the addressees, and silently dropped by lkml. Retried, set it to plain text, but somehow it still gneerated multipart html. I think I'll give up. To quote Private Frazer in Dad's Army (which probably means nothing to any of you guys) - Dooomed!"
-- seen "Linux from scratch" and looking for ISO files www.osukiss.org
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
