Bug 672856 – dev-qt/qtgui-5.11.3 - src_compile(): .../work/qtbase-everywhere-src-5.11.3/bin/qvkgen: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description tonemgub 2018-12-10 03:17:03 UTC]

Created attachment 557492 [details]
environment

[ebuild     U ] dev-qt/qtgui-5.11.3 [5.11.2-r1] USE="gif jpeg libinput png udev xcb -accessibility -dbus -debug -egl -eglfs -evdev -gles2 -ibus -test -tslib -tuio -vnc" 

I originally suspected this to be a duplicate of bug #669994, but the solution there is not working. 

Compile fails at: 
> x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -o libdl main.o    
> main.o: In function `main':
> main.cpp:(.text.startup+0x19): undefined reference to `dlopen'
> main.cpp:(.text.startup+0x21): undefined reference to `dlclose'
> main.cpp:(.text.startup+0x2a): undefined reference to `dlsym'
> main.cpp:(.text.startup+0x2f): undefined reference to `dlerror'
> collect2: error: ld returned 1 exit status
> gmake: *** [Makefile:67: libdl] Error 1

Quick search reveals it to be related to a missing -ldl linker flag, but I'm unsure how to proceed.

[Comment 1 tonemgub 2018-12-10 03:17:29 UTC]

Created attachment 557494 [details]
build.log

[Comment 2 Jeroen Roovers (RETIRED) 2018-12-10 08:40:34 UTC]

(In reply to tonemgub from comment #0)

> Compile fails at: 
> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -o libdl main.o    
> > main.o: In function `main':
> > main.cpp:(.text.startup+0x19): undefined reference to `dlopen'
> > main.cpp:(.text.startup+0x21): undefined reference to `dlclose'
> > main.cpp:(.text.startup+0x2a): undefined reference to `dlsym'
> > main.cpp:(.text.startup+0x2f): undefined reference to `dlerror'
> > collect2: error: ld returned 1 exit status
> > gmake: *** [Makefile:67: libdl] Error 1
> 
> Quick search reveals it to be related to a missing -ldl linker flag, but I'm
> unsure how to proceed.

That's just a test in src_configure(). It is resolved just below the output you quoted.

[Comment 3 Gian Luca Dalla Torre 2018-12-12 07:37:12 UTC]

I have the same problem.
I suspect that the problem lies in the old kernel I have (4.4).

I will try to upgrade to latest gentoo-sources and then recompile qtcore to see if everything will work.

[Comment 4 Gian Luca Dalla Torre 2018-12-12 22:52:42 UTC]

I confirm that, after upgrading to gentoo-sources-4.19.8 and rebuilding the kernel, qtcore and qtgui compile flawlessly.

I suspect that qtcore-5.11.3 refers to some kernel functions that are not present on old kernel versions like 4.4.4 and, during linking, they are stripped.

I do not know, however, which is the minimum version requirement for Kernel to work with this version of qt.

[Comment 5 Greg Kubaryk 2018-12-13 04:27:39 UTC]

/usr/lib/libQt5Core.so.5.11.3: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.11.0, stripped

Nice of upstream to make significant changes to the kernel requirement on a point release.

[Comment 6 Andreas Sturmlechner 2018-12-16 09:17:33 UTC]

Seems this was done there:

https://codereview.qt-project.org/#/c/242412/
https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commitdiff;h=b7887f9b4faad2227691a2af589e9d7680d6ae08

We already depend on linux-headers in dev-qt/qtgui, so we will need to raise that to >=4.11. However, I can't tell if it is still enough to make this conditional for udev/evdev only.

[Comment 7 Davide Pesavento (RETIRED) 2018-12-16 19:49:11 UTC]

The requirement of linux kernel >= 4.11 is introduced only when building against glibc >= 2.28, if statx() support is detected at build-time then Qt uses it unconditionally. I guess Qt devs are implicitly assuming that if you have such a recent glibc, you're also running a relatively new kernel.

However, it seems that there are fallbacks in the code in case the running kernel doesn't have statx (ENOSYS), so it's unclear to me why qtcore is adding a .note.ABI-tag ELF section requiring linux >= 4.11

For now, I think we can forcefully disable statx support at configure time in 5.11.3

[Comment 8 Marek Duranik 2018-12-17 07:28:00 UTC]

I have same problem with QT, but I can't switch to new kernel, because my laptop include old nvidia vga hardware. Mentioned driver of hardware supported kernel till version 4.13. Problem is, that reachable is only version 4.9.x(I use it) or 4.14.x or 4.19.x.
Could you please show me how is posible "forcefully disable statx support"?

[Comment 9 Stefan Kalis 2018-12-17 11:42:54 UTC]

Dumping 5.11.2 only one day after putting up 5.11.3 was a bit quick apparently. The mentioned previous version worked very well for me.

[Comment 10 ser666 2018-12-17 14:07:26 UTC]

Created attachment 557978 [details]
disable statx forcing kernel version

put in /etc/portage/patches/dev-qt/qtcore-5.11.3/statx.patch and reinstall qtcore

[Comment 11 Marek Duranik 2018-12-17 15:47:35 UTC]

(In reply to ser666 from comment #10)
> Created attachment 557978 [details]
> disable statx forcing kernel version
> 
> put in /etc/portage/patches/dev-qt/qtcore-5.11.3/statx.patch and reinstall
> qtcore

Thanks. It looks like it works. Graphical environment did start, but not completely. I will recompile all QT-packages of version 5.11.3 installed so far and I will try to compile rest of the QT packages prepared for upgrade.

[Comment 12 Andreas Sturmlechner 2018-12-18 19:01:30 UTC]

(In reply to Stefan Kalis from comment #9)
> Dumping 5.11.2 only one day after putting up 5.11.3 was a bit quick
> apparently.
Running ancient kernels with ~arch is a bit strange also.

You can update linux-headers separately of *-sources, did anyone actually try that yet?

[Comment 13 Stefan Kalis 2018-12-18 19:29:04 UTC]

I have linux-headers-4.19 installed. It does not cause problems but also does not solve the problem with Qt.

Qvkgen refers to Vulkan headers if I am not mistaken - this is a bit strange when Vulkan driver is disabled on my system.

[Comment 14 Andreas Sturmlechner 2018-12-18 19:40:14 UTC]

(In reply to Stefan Kalis from comment #13)
> I have linux-headers-4.19 installed. It does not cause problems but also
> does not solve the problem with Qt.
Did you rebuild glibc afterwards?

[Comment 15 Davide Pesavento (RETIRED) 2018-12-18 19:42:19 UTC]

(In reply to Andreas Sturmlechner from comment #12)
> You can update linux-headers separately of *-sources, did anyone actually
> try that yet?
I don't think linux-headers is related to this in any way. The statx() syscall wrapper is in glibc. It's the new glibc version (>= 2.28) that triggers this problem.

[Comment 16 Andreas Sturmlechner 2018-12-18 20:05:31 UTC]

(In reply to Davide Pesavento from comment #15)
> (In reply to Andreas Sturmlechner from comment #12)
> > You can update linux-headers separately of *-sources, did anyone actually
> > try that yet?
> I don't think linux-headers is related to this in any way. The statx()
> syscall wrapper is in glibc. It's the new glibc version (>= 2.28) that
> triggers this problem.

However in bug 672556 we have at least one bug report using glibc-2.27-r6.

[Comment 17 Davide Pesavento (RETIRED) 2018-12-18 20:22:04 UTC]

(In reply to Marek Duranik from comment #8)
> Could you please show me how is posible "forcefully disable statx support"?
Pass -no-feature-statx to configure.

[Comment 18 tonemgub 2018-12-20 21:44:45 UTC]

> Running ancient kernels with ~arch is a bit strange also.

I'm stuck on 4.9.x due to tons of bugs in newer versions that leave my computer unbootable. Otherwise I love ~arch

[Comment 19 Larry the Git Cow 2019-01-05 21:10:00 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fae2979e131782b514f34d775255bedd61ae92ac

commit fae2979e131782b514f34d775255bedd61ae92ac
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2018-12-30 18:08:33 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-01-05 21:09:27 +0000

    dev-qt/qtcore: Pass -no-feature-statx to configure
    
    Should fix build with older kernels.
    
    Bug: https://bugs.gentoo.org/672856
    Package-Manager: Portage-2.3.52, Repoman-2.3.12
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtcore/qtcore-5.11.3-r1.ebuild | 76 +++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

[Comment 20 Andreas Sturmlechner 2019-01-05 21:11:10 UTC]

Please test with qtcore-5.11.3-r1.

[Comment 21 Lars Wendler (Polynomial-C) (RETIRED) 2019-02-01 01:33:38 UTC]

Still not fixed. Just stumbled upon this with a very old stable amd64 system where I wanted to upgrade the userland before the kernel...

[Comment 22 Davide Pesavento (RETIRED) 2019-02-01 01:35:25 UTC]

(In reply to Lars Wendler (Polynomial-C) from comment #21)
> Still not fixed. Just stumbled upon this with a very old stable amd64 system
> where I wanted to upgrade the userland before the kernel...
What kernel version exactly?

[Comment 23 Lars Wendler (Polynomial-C) (RETIRED) 2019-02-01 01:52:25 UTC]

# uname -r
3.10.12

[Comment 24 Davide Pesavento (RETIRED) 2019-02-01 01:56:57 UTC]

Then it's bug 675858

[Comment 25 Larry the Git Cow 2020-04-12 18:09:06 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/qt.git/commit/?id=dc7faccb8dccf0e3b418bef7b23f49b004fb4208

commit dc7faccb8dccf0e3b418bef7b23f49b004fb4208
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2020-04-12 17:46:45 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2020-04-12 18:04:04 +0000

    dev-qt/qtcore: In >=5.15, disable statx only with IUSE="old-kernel"
    
    Bug: https://bugs.gentoo.org/672856
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtcore/metadata.xml               | 3 ++-
 dev-qt/qtcore/qtcore-5.15.0_beta3.ebuild | 2 +-
 dev-qt/qtcore/qtcore-5.15.9999.ebuild    | 8 ++++----
 dev-qt/qtcore/qtcore-5.9999.ebuild       | 8 ++++----
 4 files changed, 11 insertions(+), 10 deletions(-)

[Comment 26 Ben 2021-02-28 04:12:46 UTC]

Could the comment in the qtcore ebuild for this issue be clarified that it will also induce build errors if building with old kernel?

The ewarn seems to somewhat imply that this is a runtime issue versus a build issue.  I ignored the warning as I had a new kernel ready for runtime, but continued using an old kernel for bootstrap.  Therefore I ran into this bewildering bug, which is quickly solved after research finding this is indeed a build time issue.

Thanks for considering!