Summary: | x11-misc/virtualgl-2.6.1 should install VGL shared objects to another location | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | jyhpsycho |
Component: | Current packages | Assignee: | Adam Feldman <np-hardass> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | candrews, proxy-maint, rei4dan |
Priority: | Normal | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Ebuild file that fix this issue |
Attached ebuild file contains fix for this issue, too. Sorry for incomplete description. Adding candrews who did the 2.6.1 bump. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5c8df2080a700ab49e52337e8ee4424178961d31 commit 5c8df2080a700ab49e52337e8ee4424178961d31 Author: Craig Andrews <candrews@gentoo.org> AuthorDate: 2019-05-01 20:12:42 +0000 Commit: Craig Andrews <candrews@gentoo.org> CommitDate: 2019-05-01 23:35:28 +0000 x11-misc/virtualgl: EAPI=7, install to /usr/lib/VirtualGL, add dep on libXtst Closes: https://bugs.gentoo.org/683656 Closes: https://bugs.gentoo.org/679710 Package-Manager: Portage-2.3.66, Repoman-2.3.12 Signed-off-by: Craig Andrews <candrews@gentoo.org> x11-misc/virtualgl/virtualgl-2.6.1-r1.ebuild | 95 ++++++++++++++++++++++++++++ x11-misc/virtualgl/virtualgl-9999.ebuild | 6 +- 2 files changed, 99 insertions(+), 2 deletions(-) |
Created attachment 573140 [details] Ebuild file that fix this issue I'm using VirtualGL with nvidia-drivers for accelerating 3D applications over VNC. When I run `VGL_DISPLAY=:1 vglrun glxspheres64`, it throws following error: Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast Visual ID of window: 0xb6 X Error of failed request: GLXBadContext Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 31 Current serial number in output stream: 30 For debugging, I just run `LD_DEBUG=all VGL_DISPLAY=:1 vglrun glxspheres64 2>&1 | grep libGL`, and I found that it always loads /usr/lib64/libGL.so.1 (which provided by Mesa package), not /usr/lib64/opengl/nvidia/lib/libGL.so.1 (which provided by nvidia-drivers package) despite of `eselect opengl show` indicates 'nvidia'. Because of running `ldd $(which glxspheres64)` just loads correct libGL.so.1, I suspects that it caused by vglrun script. I found that vglrun loads /usr/bin/.vglrun.vars64 (it sets VGL_LIBRARY_PATH using hard-coded VGL_LIBDIR), and use it for setting LD_LIBRARY_PATH. It's clear. The application loaded by vglrun script is always run with LD_LIBRARY_PATH=${VGL_LIBDIR}, currently set to /usr/lib64. It causes always loading /usr/lib64/libGL.so.1 before searching nvidia-drivers' one, and it does not work. I found that VGL_LIBDIR variable in /usr/bin/.vglrun.vars64 is adjustable by setting CMAKE_INSTALL_LIBDIR variable during src_configure phase. I just changed it from `/usr/$(get_libdir)` to `/usr/$(get_libdir)/VirtualGL` and re-emerge VirtualGL, then it works again. It separates VirtualGL DSOs from common libraries, then it prevents /usr/lib64/libGL.so.1 from unexpected loading. I'll attach ebuild file which I use. It contains possible fix for #675282 and #679710(these are just duplicates) - adding libXtst in dependency list.