qtbase@5 doesn't work with Linux < 3.16.0

DoneSubmitted by Andréas Livet.
Details
3 participants
  • Andréas Livet
  • Ludovic Courtès
  • Ricardo Wurmus
Owner
unassigned
Severity
normal
A
A
Andréas Livet wrote on 18 Jun 2019 12:07
Not found .so files in bundle made by guix pack
(address . bug-guix@gnu.org)
e70903c2-e95f-3647-4e9b-0ca92765a0f8@livet.me
Hi,
I try to bundle scribus with guix pack in order to install it on a centos system on which admin sys doesn't want us to install guix.
So I created a tarball with a symlink to '/usr/bin' (don't know it's really the recommanded way), this way scribus binary will automatically be in the $PATH.
Here is how I created the bundle :
guix pack -S /usr/bin=bin scribus
I tried it on my Xubuntu 18.04 system and it worked like a charm.
But, when deployed on the centos machine, it did not found "libQt5Core.so.5" depsite the file exists.
ldd /gnu/store/5xqmac50axcgc8vrrn30jvzndjvrqd6a-scribus-1.5.4/bin/.scribus-real | grep Qt     libQt5Xml.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5Xml.so.5 (0x00007f60dd9f6000)     libQt5Network.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5Network.so.5 (0x00007f60dd7a4000)     libQt5OpenGL.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5OpenGL.so.5 (0x00007f60dd99a000)     libQt5PrintSupport.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5PrintSupport.so.5 (0x00007f60dd72b000)     libQt5Widgets.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5Widgets.so.5 (0x00007f60da93b000)     libQt5Gui.so.5 => /gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib/libQt5Gui.so.5 (0x00007f60da3a6000)     libQt5Core.so.5 => not found
I don't understand why it founds libQt5Gui.so.5 and not libQt5Core.so.5 which is in the same directory !
I tried to copy the .so inside the bin directory, to add qbase lib path to $LD_LIBRARY_PATH, doesn't seem to work.
Can't find any further information on guix manual, so I'm asking here.
Thanks in advance for your help,
Andréas
L
L
Ludovic Courtès wrote on 18 Jun 2019 15:51
(name . Andréas Livet)(address . andreas@livet.me)(address . 36276@debbugs.gnu.org)
875zp357du.fsf@gnu.org
Hi,
Andréas Livet <andreas@livet.me> skribis:
Toggle quote (6 lines)> Here is how I created the bundle :>> guix pack -S /usr/bin=bin scribus>> I tried it on my Xubuntu 18.04 system and it worked like a charm.
You might want to pass -RR to get a relocatable binary. :-)
Toggle quote (7 lines)> But, when deployed on the centos machine, it did not found> "libQt5Core.so.5" depsite the file exists.>> ldd> /gnu/store/5xqmac50axcgc8vrrn30jvzndjvrqd6a-scribus-1.5.4/bin/.scribus-real> | grep Qt
[...]
Toggle quote (3 lines)>     libQt5Core.so.5 => not found>
Could you make sure that LD_LIBRARY_PATH is unset?
HTH,Ludo’.
A
A
Andréas Livet wrote on 18 Jun 2019 22:21
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36276@debbugs.gnu.org)
98a2c388-3c5e-129e-4a0d-81b2e2d2860b@livet.me
Hi Ludo,
Toggle quote (2 lines)> You might want to pass -RR to get a relocatable binary. :-)
Yes, I'm uploading the new tarball on the server, it's a bit slow...
I didn't understand what did -RR option at first, but now it's seems to be a good (maybe the only?) option for installation outside the / directory (which is not a problem for me because I have root privilege on the server, just that admin sys doesn't want us to install tools like Docker, guix, etc. because he'll have to maintain the server after) .
Toggle quote (2 lines)> Could you make sure that LD_LIBRARY_PATH is unset?
Yes it is unset. This problem is driving me crazy, I can't understand why it can find libQt5Gui.so.5 and not libQt5Core.so.5
As far as I understand how dynamic linking is done under linux, the binary looks for .so files that it depends on inside folders define in the binary itself and on the operating system (/lib, /lib64).
And when it founds an .so with the corresponding name it stops, then search for another .so (if there is one).
Then how can it not found this .so file ?
* I've check it with sha1sum, it's clean.
* I check it with "nm -D" it contains all the symbols.
* I've check the binary with "chrpath -l /gnu/store/5xqmac50axcgc8vrrn30jvzndjvrqd6a-scribus-1.5.4/bin/.scribus-real", it contains "/gnu/store/890yw9i7lcjnnxhlza8r121352xpb1hi-qtbase-5.11.3/lib" which contains libQt5Core.so.5

I really can't see what's the problem here... Hope it will work with the tarball generated with -RR, but it will leave the problem unsolved...

Again, thanks for your help and what you're doing for guix,
Andréas
A
A
Andréas Livet wrote on 19 Jun 2019 13:05
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36276@debbugs.gnu.org)
2ce9bb69-56ac-b257-7d20-7f2cacc3f84d@livet.me
Hi,
I still got the problem with a pack build with -RR, I started to think about a centos bug...
If you have any ideas, let me know.
Andréas
L
L
Ludovic Courtès wrote on 19 Jun 2019 17:51
(name . Andréas Livet)(address . andreas@livet.me)(address . 36276@debbugs.gnu.org)
87zhmd1slz.fsf@gnu.org
Hi,
Andréas Livet <andreas@livet.me> skribis:
Toggle quote (8 lines)>> You might want to pass -RR to get a relocatable binary. :-)>> Yes, I'm uploading the new tarball on the server, it's a bit slow...>> I didn't understand what did -RR option at first, but now it's seems> to be a good (maybe the only?) option for installation outside the /> directory
Toggle quote (5 lines)>> Could you make sure that LD_LIBRARY_PATH is unset?>> Yes it is unset. This problem is driving me crazy, I can't understand> why it can find libQt5Gui.so.5 and not libQt5Core.so.5
Is there a /etc/ld.so.preload file?
Did you try running the pack on another non-Guix machine?
Thanks,Ludo’.
A
A
Andréas Livet wrote on 20 Jun 2019 20:25
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36276@debbugs.gnu.org)
06e405a8-9157-f3bf-f983-26fc46679369@livet.me
Hi,
Toggle quote (4 lines)> https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/> explains ‘-R’, and> <https://www.gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released/>> mentions ‘-RR’.
Thanks for the documentation :)
Toggle quote (1 lines)> Is there a /etc/ld.so.preload file?
No. Only some very simples ld.so.config in /etc/ld.so.conf.d
Toggle quote (2 lines)> Did you try running the pack on another non-Guix machine?
I tried yesterday I works as expected on a Xubuntu 16.04 machine without guix installed on it.
Don't have much time to investigate on it.
For information, it's a CentOS 7.6.1810 server which I did not configure from the beginning, so I don't know precisely which changes has been made on it...
I think, maybe there is a conflict of another libQt5Core (not 5) installed on the machine ?
Anyway, thanks for your help,
Andréas
L
L
Ludovic Courtès wrote on 21 Jun 2019 16:47
(name . Andréas Livet)(address . andreas@livet.me)(address . 36276@debbugs.gnu.org)
87imszhu6b.fsf@gnu.org
Hello,
Andréas Livet <andreas@livet.me> skribis:
Toggle quote (3 lines)>> Is there a /etc/ld.so.preload file?> No. Only some very simples ld.so.config in /etc/ld.so.conf.d
Hmm, can you try temporarily moving them out of the way to see if itmakes a difference?
AFAICS only /etc/ld.so.preload is accessed, but who knows.
Toggle quote (7 lines)> For information, it's a CentOS 7.6.1810 server which I did not> configure from the beginning, so I don't know precisely which changes> has been made on it...>> I think, maybe there is a conflict of another libQt5Core (not 5)> installed on the machine ?
That could be the case, but only if there’s LD_LIBRARY_PATH,ld.so.preload, or something like that interfering.
What if you run:
env -i …/bin/scribus
where you replace “…” with the full file name of your extracted pack?
HTH,Ludo’.
A
A
Andréas Livet wrote on 24 Jun 2019 18:10
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36276@debbugs.gnu.org)
70570cd6-1a97-8acc-6575-cf9a5329fc33@livet.me
Hi !
Found a solution !
https://superuser.com/a/1348051
Don't really understand why I got this problem which seems to be WSL only...
Do you think it is related to guix pack in some way ?
Thank you,
Andréas
L
L
Ludovic Courtès wrote on 24 Jun 2019 21:19
(name . Andréas Livet)(address . andreas@livet.me)(address . 36276@debbugs.gnu.org)
87sgry7puv.fsf@gnu.org
Hello,
Andréas Livet <andreas@livet.me> skribis:
Toggle quote (4 lines)> Found a solution !>> https://superuser.com/a/1348051
Good! So you ran:
strip --remove-section=.note.ABI-tag \ ./gnu/store/…/lib/libQt5Core.so.5
right?
Indeed the .so file produced by Guix has this section:
Toggle snippet (4 lines)$ file -L /gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so/gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.16.0, stripped
… which reflects in the “for GNU/Linux 3.16.0” that we see above.
What does “uname -r” return on this CentOS machine? I’m guessing it’solder than 3.16.0.
The effect of the ‘strip’ command is that libQt5Base.so can be loaded,but some functionality maybe missing (things that use the ‘renameat2’system call specifically; see below.)
Toggle quote (2 lines)> Do you think it is related to guix pack in some way ?
I researched it a bit and in qtbase, in‘src/corelib/global/minimum-linux_p.h’, we can see this:
Toggle snippet (15 lines)#if QT_CONFIG(getentropy)# define MINLINUX_MAJOR 3# define MINLINUX_MINOR 17# define MINLINUX_PATCH 0#elif QT_CONFIG(renameat2)# define MINLINUX_MAJOR 3# define MINLINUX_MINOR 16# define MINLINUX_PATCH 0#else# define MINLINUX_MAJOR 2# define MINLINUX_MINOR 6# define MINLINUX_PATCH 28#endif
Since we build Qt with ‘renameat2’ support, Qt effectively requires aLinux kernel >= 3.16.0.
We could build it without that requirement; 3.16.0 is already ratherold, so I’m not sure we should do it.
Thoughts?
(Note that the Guix package already has a patch to allow it to work withkernels < 4.11.)
Ludo’.
A
A
Andréas Livet wrote on 25 Jun 2019 10:38
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36276@debbugs.gnu.org)
48bbff6b-bd6f-b056-26d9-8c82ec3aba7d@livet.me
Hello,
Toggle quote (6 lines)> Good! So you ran:>> strip --remove-section=.note.ABI-tag \> ./gnu/store/…/lib/libQt5Core.so.5>> right?
Yes exactly :).
Toggle quote (12 lines)>> Indeed the .so file produced by Guix has this section:>> --8<---------------cut here---------------start------------->8---> $ file -L /gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so> /gnu/store/y1nlilwa34wqvmvmraggwv12jfdp0kya-qtbase-5.11.3/lib/libQt5Core.so: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.16.0, stripped> --8<---------------cut here---------------end--------------->8--->> … which reflects in the “for GNU/Linux 3.16.0” that we see above.>> What does “uname -r” return on this CentOS machine? I’m guessing it’s> older than 3.16.0.
> 3.10.0-957.12.2.el7.x86_64
What a shame, this kernel was release in 2013 !
I start to think that our VM was not installed properly because regular centos install seems to have a much more recent kernel...
Toggle quote (24 lines)> The effect of the ‘strip’ command is that libQt5Base.so can be loaded,> but some functionality maybe missing (things that use the ‘renameat2’> system call specifically; see below.)>>> Do you think it is related to guix pack in some way ?> I researched it a bit and in qtbase, in> ‘src/corelib/global/minimum-linux_p.h’, we can see this:>> --8<---------------cut here---------------start------------->8---> #if QT_CONFIG(getentropy)> # define MINLINUX_MAJOR 3> # define MINLINUX_MINOR 17> # define MINLINUX_PATCH 0> #elif QT_CONFIG(renameat2)> # define MINLINUX_MAJOR 3> # define MINLINUX_MINOR 16> # define MINLINUX_PATCH 0> #else> # define MINLINUX_MAJOR 2> # define MINLINUX_MINOR 6> # define MINLINUX_PATCH 28> #endif> --8<---------------cut here---------------end--------------->8---
Well done :D, I didn't have time to investigated as far as you did.
Toggle quote (8 lines)> Since we build Qt with ‘renameat2’ support, Qt effectively requires a> Linux kernel >= 3.16.0.>> We could build it without that requirement; 3.16.0 is already rather> old, so I’m not sure we should do it.>> Thoughts?
IMHO, don't bother, as you say 3.16.0 is already very old so it's OK to let it this way.
Maybe it could be worth to mention in guix pack manual that bundle may not always works on too old kernel ?
Difficult to be precise because it'll depends on projects, don't really know how to write it down in a way it'll help people to understand problems like this one.
Thanks again for your hard work,
Andréas
R
R
Ricardo Wurmus wrote on 25 Jun 2019 13:34
(name . Andréas Livet)(address . andreas@livet.me)
87tvcdsxsy.fsf@elephly.net
Hi Andréas,
Toggle quote (9 lines)>> What does “uname -r” return on this CentOS machine? I’m guessing it’s>> older than 3.16.0.>> 3.10.0-957.12.2.el7.x86_64>> What a shame, this kernel was release in 2013 !>> I start to think that our VM was not installed properly because> regular centos install seems to have a much more recent kernel...
I’m afraid not. This is the kernel version on an arbitrary node runningCentOS 7.4.1708: 3.10.0-693.21.1.el7.x86_64
RHEL 7.x won’t ever include any kernel version higher than 3.10.0.Until it goes EOL they’ll merely backport fixes and sometimes APIs towhat they call 3.10.0, but which won’t be anywhere close to what avanilla 3.10.0 kernel provides.
The same happened on RHEL 6, which still provides what they call 2.6.32,which is nothing like vanilla 2.6.32.
Sometimes that heavily patched kernel will include an interface thatlater versions introduced and thus the kernel version checks will beinaccurate. We had this problem with the RHEL 6 kernel and the GNU Clibrary, which is why we patched the glibc to make an exception forLinux version 2.6.32 (which only in its RHEL 6 variant provides therequired interfaces).
--Ricardo
L
L
Ludovic Courtès wrote on 25 Jun 2019 16:06
(name . Andréas Livet)(address . andreas@livet.me)(address . 36276@debbugs.gnu.org)
87h88dn4iv.fsf@gnu.org
Hello,
Andréas Livet <andreas@livet.me> skribis:
Toggle quote (6 lines)>> What does “uname -r” return on this CentOS machine? I’m guessing it’s>> older than 3.16.0.>> 3.10.0-957.12.2.el7.x86_64>> What a shame, this kernel was release in 2013 !
Yeah.
Toggle quote (20 lines)>> ‘src/corelib/global/minimum-linux_p.h’, we can see this:>>>> --8<---------------cut here---------------start------------->8--->> #if QT_CONFIG(getentropy)>> # define MINLINUX_MAJOR 3>> # define MINLINUX_MINOR 17>> # define MINLINUX_PATCH 0>> #elif QT_CONFIG(renameat2)>> # define MINLINUX_MAJOR 3>> # define MINLINUX_MINOR 16>> # define MINLINUX_PATCH 0>> #else>> # define MINLINUX_MAJOR 2>> # define MINLINUX_MINOR 6>> # define MINLINUX_PATCH 28>> #endif>> --8<---------------cut here---------------end--------------->8--->> Well done :D, I didn't have time to investigated as far as you did.
I didn’t “have” the time, I took it. :-)
Toggle quote (3 lines)> IMHO, don't bother, as you say 3.16.0 is already very old so it's OK> to let it this way.
Sounds good.
Toggle quote (7 lines)> Maybe it could be worth to mention in guix pack manual that bundle may> not always works on too old kernel ?>> Difficult to be precise because it'll depends on projects, don't> really know how to write it down in a way it'll help people to> understand problems like this one.
Yes, it’s a bit hard to document it because it’ll vary from package topackage, and the vast majority of packages don’t care about the kernelversion.
Anyway, thanks for your report, and I hope you can find a suitableworkaround!
Ludo’.
L
L
Ludovic Courtès wrote on 25 Jun 2019 16:06
control message for bug #36276
(address . control@debbugs.gnu.org)
87ftnxn4hw.fsf@gnu.org
retitle 36276 qtbase@5 doesn't work with Linux < 3.16.0quit
L
L
Ludovic Courtès wrote on 25 Jun 2019 16:06
(address . control@debbugs.gnu.org)
87ef3hn4hp.fsf@gnu.org
tags 36276 wontfixclose 36276quit
?
Your comment

This issue is archived.

To comment on this conversation send email to 36276@debbugs.gnu.org