/usr/lib/libvglfaker.so: undefined symbol: glXGetProcAddressARB

[DerPit]

I am getting the above error when trying to run some application (game). Reading through the issues here, it seems related to issues #102 and #60 but as my setup is somewhat different I decided to better open a separate issue.

Background: I have an Optimus chip in my Laptop (HD530/940MX) and use bumblebee/optirun to launch single applications, which starts a separate X server and then uses vglrun to connect to it. This works w/o issues for, e.g., glxspheres or google-earth-pro. For others, like the game 'Victor Vran', it wont, giving this:

woodstock:game% optirun ./VictorVranGOG
[VGL] NOTICE: Added /usr/lib64/nvidia:/usr/lib/nvidia to LD_LIBRARY_PATH
./VictorVranGOG: /usr/lib/libldap_r-2.4.so.2: no version information available (required by libcurl-gnutls.so.4)
./VictorVranGOG: /usr/lib/liblber-2.4.so.2: no version information available (required by libcurl-gnutls.so.4)
[VGL] Shared memory segment ID for vglconfig: 917535
[VGL] VirtualGL v2.6.4 32-bit (Build 20200706)
[VGL] NOTICE: Replacing dlopen("libGL.so.1") with dlopen("libvglfaker.so")
[VGL] Opening connection to 3D X server :8
[VGL] ERROR: Could not load GLX/OpenGL functions
[VGL]    /usr/lib/libvglfaker.so: undefined symbol: glXGetProcAddressARB

(this is with VGL_VERBOSE=1). I do get the same error if I use vglrun directly, which connects to the 'real' X server :0.0 using the HD530 graphics. That's why I came here, as it seems to be an VGL issue.

Trying various things (without really knowing what I do....) I tried 'vglrun -nodl', and that one, on the local X server, starts the game. But not if I pass the '-nodl' as option for vglrun to optirun - then I only get a warning window that the game requires 3D acceleration.
As mentioned in one of the other issues, also for me an 'nm /usr/lib/libvglfaker.so' shows that glXGetProcAddressARB is defined in there....

My system is an up-to-date openSUSE Tumbleweed (20200905), using the systems VirtualGL-2.6.4-49.4
(https://build.opensuse.org/package/show/X11:Bumblebee/VirtualGL)

As it seems to be a recurring thing - any ideas what the cause is? The other reports (to me) didn't suggest a solution :(

[DerPit]

Just found #16 (comment). The workaround suggested there, supplying the proper VGL_GLLIB, does work for me, too.
Both
VGL_GLLIB=/usr/lib/libGL.so.1 vglrun ./VictorVranGOG
and
VGL_GLLIB=/usr/lib/nvidia/libGL.so.1 optirun ./VictorVranGOG
run the game without errors on the intel/nvidia card.

[dcommander]

That shouldn’t be necessary with the official VirtualGL build, but unfortunately, on multiple occasions, people have repackaged VGL in ways that fundamentally broke it. If you can reproduce the same issue using our official packages, then I’ll treat it as a VGL bug, but it really does appear to me to be a symptom of a broken downstream package.

[DerPit]

Seems there's no official rpm package to get the 32bit libs on a 64bit system - so difficult to verify

[dcommander]

SuSE doesn't support the same 32-bit/64-bit co-install capabilities that RHEL/CentOS does. You can install both 64-bit and 32-bit official RPMs on a 64-bit SuSE system. You just have to use rpm --force.

[DerPit]

I rather unpacked the rpms and combined and installed manually. Indeed, those do work without error.
I've opened a downstream bugreport here: https://bugzilla.opensuse.org/show_bug.cgi?id=1176422

[dcommander]

OK, it's probably the same issue that was once encountered with the Arch and Fedora packages, then-- the downstream maintainer didn't link libvglfaker.so with libGL. There are all sorts of rules that Linux distributions place upon shared libraries, and some of those rules are enforced without any regard for how they might break interposer libraries such as the ones in VirtualGL. The package maintainers may have considered the direct libGL linkage unnecessary, since libvglfaker.so always uses dlopen() to load functions from libGL. In fact, that linkage is not necessary when using applications that themselves link directly with libGL (which is why libvglfaker-nodl.so is not linked with libGL), but in order to use VirtualGL with applications that themselves use dlopen() to load functions from libGL, the faker libraries must be linked with libGL or VGL_GLLIB must be specified. That would explain why some applications worked for you but others didn't.

[DerPit]

Hey, thanks a lot for these thoughts! Yes, you are most likely right. If I compare the TW version with your official one, ldd indeed doesn't show libGL.so.1 (and libGLX.so + libGLdispatch.so)