Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 683656 - x11-misc/virtualgl-2.6.1 should install VGL shared objects to another location
Summary: x11-misc/virtualgl-2.6.1 should install VGL shared objects to another location
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Adam Feldman
URL:
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2019-04-17 06:23 UTC by jyhpsycho
Modified: 2019-05-01 23:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild file that fix this issue (virtualgl-2.6.1-r999.ebuild,2.65 KB, text/plain)
2019-04-17 06:23 UTC, jyhpsycho
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jyhpsycho 2019-04-17 06:23:23 UTC
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.
Comment 1 jyhpsycho 2019-04-17 06:26:26 UTC
Attached ebuild file contains fix for this issue, too. Sorry for incomplete description.
Comment 2 Andreas Sturmlechner gentoo-dev 2019-05-01 08:38:59 UTC
Adding candrews who did the 2.6.1 bump.
Comment 3 Larry the Git Cow gentoo-dev 2019-05-01 23:35:36 UTC
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(-)