Summary: | x11-base/xorg-server-1.20.7[libglvnd]: error: ld:[...]../lib64/libGL.so: undefined reference to `_glapi_tls_Current' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Frömmel <cfroemmel> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | contactme, dechcaudron, fedyanin, gentoo-bugs-augustin, info, ionen, me, mjo, paul, pclouds |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=739900 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log (tar gz) |
Description
Christopher Frömmel
2020-03-07 10:58:28 UTC
Created attachment 617396 [details]
build log (tar gz)
That was before it became default, but I ran into the same error when I flipped libglvnd all at once (with nvidia-drivers included). I also use [xvfb] I don't remember the specifics but I thought it may be an order issue, so I rebuilt one by one using --nodeps to force it, and finally xorg-server _last_, which built with no errors. I wasn't sure if it was just me doing weird things at the time so I opted not to fill a bug without further testing. _glapi_tls_Current symbol is supposed to be defined in libGLdispatch.so.0, and libGL.so should be linked against libGLdispatch.so.0: # (cd /var/tmp/portage/media-libs/libglvnd-1.3.1/image; scanelf -qyRF "%F: %s" -s "+_glapi_tls_Current" *) usr/lib64/libGLdispatch.so.0.0.0: _glapi_tls_Current # (cd /var/tmp/portage/media-libs/libglvnd-1.3.1/image; scanelf -qyRF "%F: %s" -s "-_glapi_tls_Current" *) usr/lib64/libOpenGL.so.0.0.0: _glapi_tls_Current usr/lib64/libGLESv1_CM.so.1.2.0: _glapi_tls_Current usr/lib64/libGLESv2.so.2.1.0: _glapi_tls_Current usr/lib64/libGL.so.1.7.0: _glapi_tls_Current # (cd /var/tmp/portage/media-libs/libglvnd-1.3.1/image; scanelf -qyRF "%F: %n" *) usr/lib64/libOpenGL.so.0.0.0: libGLdispatch.so.0,libc.so.6 usr/lib64/libEGL.so.1.1.0: libGLdispatch.so.0,libdl.so.2,libc.so.6 usr/lib64/libGLESv1_CM.so.1.2.0: libGLdispatch.so.0,libc.so.6 usr/lib64/libGLdispatch.so.0.0.0: libdl.so.2,libc.so.6 usr/lib64/libGLX.so.0.0.0: libGLdispatch.so.0,libdl.so.2,libX11.so.6,libc.so.6 usr/lib64/libGLESv2.so.2.1.0: libGLdispatch.so.0,libc.so.6 usr/lib64/libGL.so.1.7.0: libGLdispatch.so.0,libGLX.so.0,libc.so.6 Can you check linking and symbols in your libraries? In my case, mid-way into the transition, I think it may have tried to use /usr/lib/opengl/nvidia/lib/libGL* libraries I vaguely recall my emerge -uUD @world did xorg-server _before_ nvidia+libglnvd. Thus why emerging it with --nodeps first, and then building xorg-server fixed it. But that means anyone with a similar setup may run into the same problem. Had the same problem, and I can confirm that Ionen's solution fixes the problem. I've heard this also happen with other packages that use opengl if built before nvidia-drivers[+libglvnd] is rebuilt. nvidia-drivers[+libglvnd] is essentially a mesa alternative (headers + libraries), but almost nothing depends on it so orders likely get wrong. Well, it does lack GL/internal/dri_interface.h (provided by mesa) that xorg-server uses for it's non-vendor-independant GLX that nvidia users aren't even using. Otherwise everything works without mesa on nvidia-only. Thanks for your useful informations! Simple steps that fixed that build order problem (with +libglvnd) for me: 1) emerge --nodeps -1 nvidia-drivers 2) emerge -1 mesa xorg-server Hello Christopher, I think you shouldn’t close this bug yet, until it is resolved (or marked as) by a Gentoo dev, and for people trying to find this bug when requesting the string "libGL.so: undefined reference to `_glapi_tls_Current'", by default Bugzilla only seek for opened issues. Best regards, You are right. In my world WORKSFORME was not a true "resolved". Hm, I guess I need to put some blocker dependencies in place to ensure nvidia-drivers is rebuilt before xorg-server. I'm affected by this issue as well. Thanks to Christopher for the WA. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb625716155c239585d752e7c19d113afdeb91af commit cb625716155c239585d752e7c19d113afdeb91af Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-03-09 00:04:45 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-03-09 00:07:22 +0000 x11-base/xorg-server: Block on nvidia-drivers[-libglvnd] If nvidia-drivers are installed without libglvnd support, the Xserver will fail to build. Closes: https://bugs.gentoo.org/711780 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-base/xorg-server/xorg-server-1.20.7.ebuild | 1 + x11-base/xorg-server/xorg-server-9999.ebuild | 1 + 2 files changed, 2 insertions(+) Added a blocker. Let's see if that solves it. (In reply to Matt Turner from comment #13) > Added a blocker. Let's see if that solves it. Adding the blocker solved the issue for me The "ebuild -uDNv world" - which failed yesterday - completes successfully in the right order: $ emerge -uDNva world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-libs/mesa-19.3.4-r1::gentoo [19.3.4::gentoo] USE="X classic dri3 egl gallium gbm gles2 libglvnd llvm vaapi vdpau xvmc -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa -pax_kernel (-selinux) -test -unwind -valgrind -vulkan -vulkan-overlay -wayland -xa" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="i965 intel (-freedreno) -i915 -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB [ebuild R ] x11-drivers/nvidia-drivers-440.59:0/440::gentoo USE="X acpi driver gtk3 kms libglvnd* multilib tools uvm -compat -static-libs -wayland" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild R ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo USE="ipv6 libglvnd* suid udev xorg xvfb -debug -dmx -doc -elogind -kdrive -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest" 0 KiB [uninstall ] app-eselect/eselect-opengl-1.3.1-r4::gentoo [blocks b ] app-eselect/eselect-opengl ("app-eselect/eselect-opengl" is blocking x11-drivers/nvidia-drivers-440.59, media-libs/mesa-19.3.4-r1, x11-base/xorg-server-1.20.7) Total: 3 packages (1 upgrade, 2 reinstalls, 1 uninstall), Size of downloads: 0 KiB Conflict: 1 block Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Running pre-merge checks for media-libs/mesa-19.3.4-r1 * Ignoring USE=vaapi since VIDEO_CARDS does not contain r600, radeonsi, or nouveau * Ignoring USE=vdpau since VIDEO_CARDS does not contain r300, r600, radeonsi, or nouveau * Ignoring USE=xvmc since VIDEO_CARDS does not contain r600 or nouveau >>> Running pre-merge checks for x11-drivers/nvidia-drivers-440.59 * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 5.5.8-x86_64 * Checking for suitable kernel configuration options... [ ok ] >>> Emerging (1 of 3) media-libs/mesa-19.3.4-r1::gentoo >>> Installing (1 of 3) media-libs/mesa-19.3.4-r1::gentoo >>> Emerging (2 of 3) x11-drivers/nvidia-drivers-440.59::gentoo >>> Installing (2 of 3) x11-drivers/nvidia-drivers-440.59::gentoo >>> Emerging (3 of 3) x11-base/xorg-server-1.20.7::gentoo >>> Installing (3 of 3) x11-base/xorg-server-1.20.7::gentoo >>> Uninstalling app-eselect/eselect-opengl-1.3.1-r4::gentoo >>> Jobs: 3 of 3 complete Load avg: 1.93, 1.35, 0.72 * Messages for package media-libs/mesa-19.3.4-r1: * Log file: /var/log/portage/media-libs:mesa-19.3.4-r1:20200309-115217.log * Ignoring USE=vaapi since VIDEO_CARDS does not contain r600, radeonsi, or nouveau * Ignoring USE=vdpau since VIDEO_CARDS does not contain r300, r600, radeonsi, or nouveau * Ignoring USE=xvmc since VIDEO_CARDS does not contain r600 or nouveau >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. Thanks! Excellent! Thanks a ton for confirming! Unfortunately the solution also affects =x11-drivers/nvidia-drivers-340.108 that is still in the tree, stable and is used for older cards. This version does not have a `libglvnd' flag and blocks break a build. Probably <x11-drivers/nvidia-drivers-435.21-r1 won't build as well. In reply to comment #6 by Ionen Wolkens: > I've heard this also happen with other packages that use opengl if built > before nvidia-drivers[+libglvnd] is rebuilt. I had the exact same error message with another package: >>> Failed to emerge dev-qt/qtdeclarative-5.14.2-r2: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/libGL.so: undefined reference to `_glapi_tls_Current' collect2: error: ld returned 1 exit status At that time, media-libs/libglvnd had already successfully emerged. However neither x11-base/xorg-server-1.20.8 [1.20.7] USE="elogind* libglvnd*" nor x11-drivers/nvidia-drivers-440.82-r3 had emerged yet. The solution by Christopher Frömmel in comment #7 worked for me: 1) emerge --nodeps -1 nvidia-drivers 2) continue emerge --update, during which dev-qt/qtdeclarative emerged successfully. So, it appears that there are other instances of this bug that are not yet fixed. Also, I am grateful for the comments above, that provided the solution in my specific situation. However, I am wondering, given the error message above (undefined symbol in libGL.so)... how would someone deduce that the nvidia-drivers needed to be rebuilt first? What kind of educated guess could I make in the future to deduce how to solve similar problems in the future? Thank you all. If anybody has some answers or pointers to my last question (previous comment), I'd like to document it here: https://linux.overshoot.tv/dev-qt/qtdeclarative https://linux.overshoot.tv/usr/lib64/libGL.so This fix has broken the most convenient way to deal with legacy nvidia drivers with no libglvnd support located here: https://gitlab.com/shibotto/nvidia-legacy. (In reply to Georgi from comment #19) > This fix has broken the most convenient way to deal with legacy nvidia > drivers with no libglvnd support located here: > https://gitlab.com/shibotto/nvidia-legacy. I don't see how it could have because this bug's commit is older than the overlay. Cross-posted here in case of confusion, but let's continue this on the forums if in doubt: https://forums.gentoo.org/viewtopic-p-8549832.html#8549832 I apologize for my previous comment. The issue was on my side. Regards, Georgi |