optirun fails to run glxgears reporting undefined symbol: _glapi_tls_Current

as per title, when running glxgears (and any other application by far) i get the following

francesco@darkstar:/usr/lib64$ optirun -v glxgears
[ 2634.437737] [INFO]Configured driver: nvidia
[ 2635.153372] [INFO]Response: Yes. X is active.
[ 2671.299568] [INFO]Running application using primus.
primus: fatal: failed to load any of the libraries: /usr/$LIB/libGL.so.1:/usr/lib/$LIB/libGL.so.1:/usr/$LIB/mesa/libGL.so.1:/usr/lib/$LIB/mesa/libGL.so.1
/usr/lib64/libGL.so.1: undefined symbol: _glapi_tls_Current
/usr/lib/$LIB/libGL.so.1: cannot open shared object file: No such file or directory
/usr/$LIB/mesa/libGL.so.1: cannot open shared object file: No such file or directory
/usr/lib/$LIB/mesa/libGL.so.1: cannot open shared object file: No such file or directory

Something similar happens if I use primusrun instead of optirun.
This happened after i updated like 30 or 40 packages from -current, so I can't really know which broke it. I already tried to update the NVIDIA driver to 418.74 (the last stable) and rebuild the whole Bumblebee (using the develop branch)

any idea?

worth noting that:

francesco@darkstar:/usr/lib64$ readelf -Ws /usr/lib64/libGL.so | grep tls
    18: 0000000000000000     0 TLS     GLOBAL DEFAULT  UND _glapi_tls_Current

so the symbol is actually there

Did you install the new libglvnd? If not, the NVIDIA driver may have installed incompatible versions of the GL libraries, so if you missed that you'll want to install libglvnd and then reinstall mesa. After that, install the NVIDIA driver again using the .run installer.

As an aside - I'm no longer convinced that libglvnd is a great idea and I'm considering rolling back to mesa without it. I'll gladly accept any advice about that.

Yes I installed it. And I just discovered that it was the package the broke down all, because I'm using Bumblebee. The original .run file seems not to create problem, but the architecture of my notebook doesn't let me use the NVIDIA driver without using Primus. Removing files from /usr/lib64/nvidia-bumblebee that libglvnd already provides allows me to run firefox or start glxgears or obs. The last two crashes after a bit though

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  11 (X_GLXSwapBuffers)
  Serial number of failed request:  40
  Current serial number in output stream:  41
primus: warning: dropping a frame to avoid deadlock
primus: warning: timeout waiting for display worker
terminate called without an active exception

EDIT: removing libglvnd and recompile mesa without it restored full functionality. If is not needed, I don't see why provide the package, since NVIDIA already provides it builtin

Originally Posted by Francexi EDIT: removing libglvnd and recompile mesa without it restored full functionality. If is not needed, I don't see why provide the package, since NVIDIA already provides it builtin

The rationale is that if it's installed, then NVIDIA uses the system version and doesn't replace any system files. But rationale to get rid of it and go back to how things were previously is that it's looking to be more of a problem than a benefit, based on initial reports. Looks like everyone else has gone to mesa+libglvnd now... and I let them do that since last year before taking the plunge.

There are also reports that mesa+libglvnd won't work at all with the NVIDIA legacy driver, and that's clearly no bueno.

it definitely is a problem unless NVIDIA (or AMD) doesn't provide a actually usable way to manage Notebook systems without making use of Bumblebee(or, in case of AMD, a lot of complex configurations, that also don't fully work), or have headaches for weeks

I really have no idea what's involved in bumblebee, but considering other distros switched years ago I'm sure it's just a matter of adapting for the new environment. I looked around a bit and found this bug report for primus that could help in fixing things up for libglvnd: https://github.com/amonakov/primus/issues/193

Originally Posted by ppr:kut I really have no idea what's involved in bumblebee, but considering other distros switched years ago I'm sure it's just a matter of adapting for the new environment. I looked around a bit and found this bug report for primus that could help in fixing things up for libglvnd: https://github.com/amonakov/primus/issues/193

Bumblebee is involved because when building nvidia-bumblebee package, the package includes the libraries provided by libglvnd and optirun has problem in choosing which to use, messing up things. Removing manually files that are in /usr/lib64/nvidia-bumblebee that are listed in the libglvnd make the system somewhat usable but still, when trying to run something that uses GLX (like glx gears) you obtain:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  11 (X_GLXSwapBuffers)
  Serial number of failed request:  40
  Current serial number in output stream:  41
primus: warning: dropping a frame to avoid deadlock
primus: warning: timeout waiting for display worker
terminate called without an active exception

I won't mind patch the nvidia-bumblebee slackbuild into removing unneeded files, if we find out how to make it correctly work. The files (and links) I removed are:

libEGL.so.1
libEGL.so.1.1.0
libGL.so
libGL.so.1
libGL.so.1.7.0
libGLESv1_CM.so.1
libGLESv1_CM.so.1.2.0
libGLESv2.so.2
libGLESv2.so.2.1.0
libGLX.so
libGLX.so.0
libGLdispatch.so
libGLdispatch.so.0
libOpenGL.so
libOpenGL.so.0

What I meant was I don't know what's involved in setting bumblebee up/configuring it, or how it's supposed to work.
I'm afraid I can't help you much with that, but from what I see in other distros, there is no special nvidia-bumblebee package. It's using the same install as a standalone configuration.
Your best bet is probably to look how other distros do it.

that's because bumblebee is needed only in headless configuration (ex: Intel + NVIDIA) where the system can't rely only on the dedicated video card

I know what it's for. I assume that pre-libglvnd it needed to keep track of mesa's libGL/libEGL and nvidia's since either driver needed their own and bumblebee needed a way to switch between them. But with libglvnd that's no longer necessary. There's no conflicting files, it just needs to tell libglvnd which backend driver to use.

All the info I can find says it works just fine. For example: https://docs.fedoraproject.org/en-US...ibglvnd-issues

Originally Posted by ppr:kut I know what it's for. I assume that pre-libglvnd it needed to keep track of mesa's libGL/libEGL and nvidia's since either driver needed their own and bumblebee needed a way to switch between them. But with libglvnd that's no longer necessary. There's no conflicting files, it just needs to tell libglvnd which backend driver to use. All the info I can find says it works just fine. For example: https://docs.fedoraproject.org/en-US...ibglvnd-issues

The method they suggest (bumblebee-nvidia --force) is not available on Slackware since the Slackbuild doesn't provide it)

EDIT: I edited primusrun adding the line __GLVND_DISALLOW_PATCHING=1. Now seems to work using the default -current packages and removing from the /usr/lib64/nvidia-bumblebee the already provided packages