On 07/21/2019 04:04 PM, Bruce Dubbs via blfs-dev wrote:
On 7/21/19 2:37 PM, Jean-Marc Pigeon via blfs-dev wrote: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. -- BruceMy 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 its code 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" :) .How is this workaround any worse than including linux/sockios.h ?
Because it is a Hexadecimal value coming from nowhere.
I'm sure that Qt and/or glibc will provide a proper change relatively soon. As I said, the workaround is temporary.
I was NOT trying to be mean, I understood is was temporary. (I was not even trying to insinuate "my patch was better than your") I tried to elevate our exchange saying QT should/must be OS unaware and it will a noble task for BLSF to make QT upstream aware about such situation (if you see BLFS team as an integrator team). The fact QT (and as I understand it other high level application) are OS definitions dependant is amazing to me. (having compilation crash because you move from linux 5.1 to 5.2 is a no-no for such High level tools). Sure WE (WE as software designer, me, you, the list, etc.) can patch the code.... but sometime patch can NOT be applied properly if you do not understand what is your application layer and the design constraint involved.. Think about the Boeing Max Software Team....Why it take so long to fix an apparent simple bug...
-- Bruce
-- 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
