Hello,
Good! So you ran:
strip --remove-section=.note.ABI-tag \
./gnu/store/…/lib/libQt5Core.so.5
right?
Yes exactly :).
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...
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.
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
