Don't let Qt require a minimum kernel of 3.17+ (even if we're building against headers satisfying that requirement) #40577
Conversation
Before this change:
$ readelf --notes /nix/store/zf5yja02g8n8dzgs25pqfd8w3myfzgzc-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7778 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.17.0
After:
$ readelf --notes /nix/store/sg1s9hdw0b7p6h0dwg09g4lxy1acq7y6-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7dcc with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.28
-----------
The above paths were before rebasing the commit onto staging,
and it'd probably be good to have someone confirm the same happens
when built on a hydra builder or other non-dtzWill machine :).
|
I'm confused. The code at http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp?h=dev first tries |
|
Ah now I get what you mean: Well that's crazy. I wonder what's causing the kernel version tag to be emitted. |
|
If no libc wrapper is detected (not avail in our glibc, unsure what version adds it), but SYS_renameat2 is defined (new kernel headers), qt emits its own syscall wrapper and sets kernel version requirement (non-standard, glibc-only). Handling I also found the logs a bit confusing at first, since they report that checks for these functions ( I didn't track down where the version is set, would be curious how they manage to tie that into their build system. (understanding this isn't important, just curious) |
|
IMHO this should be backported to 18.03 as well. Perhaps sent to staging-18.03 first, if we're doing that? :) |
Right, that should be reported as a Qt bug. There is no reason to do anything like that, checking for But yes, in the meantime, let's merge this. |
|
(Should we wait to hear from @ttuegel?) |
|
Applied in 39696b6. I added some comments. |
No 😉 applying this was the right thing to do. Is this backported to 18.03 yet? (It doesn't look like it, to me.) If not, I'm happy to take care of it. |
|
@ttuegel if it's no trouble, please do so if you haven't already! Also can we pick this to master too? :3. Or do we think staging will be merged soon-ish? |
|
Applied in a7b6a91. |
Running an ubuntu 18 container on a CentOS 7 system warned about libQt5Core.so not being found. Binaries were checked for correct RUNPATHs and found to be o.k. Other Qt libraries were found and loaded without issue. Probable cause found to be Qt encoding kernel ABI into library (and thus container shared kernel not supporting this) per report here: NixOS/nixpkgs#40577 Use same set of arguments in that patch to build binaries with compatibility for older kernels.
Fixes #38832.
Fixes use of qt 5.10 on many distributions not shipping 3.17 or newer.
I believe even kernels with these features --if such exist-- won't work since
the check is specifically for version and not for the features in question.
This is especially "unfortunate" since libraries requiring versions newer
than what is available are silently overlooked during searches,
resulting in messages indicating that "libFoo.so" cannot be found
(instead of "libFoo.so found but requires kernel X.Y, you're running A.B" or whatever).
As indicated in the commit, someone checking this situation would be appreciated :).
And to be completely clear, this compatibility is achieved by disabling use of
the
renameat2andgetentropysyscalls (even if they are supported);this does not seem problematic to me but is something to be considered.
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)