There are issues when opening i915_dri.so, the function _glapi_tls_Dispatch is undefined. $ nm -D /usr/lib/libGL.so | grep glapi U _glapi_check_multithread U _glapi_get_dispatch_table_size U _glapi_get_proc_address U _glapi_get_proc_offset U _glapi_set_context U _glapi_set_dispatch U _glapi_tls_Dispatch U = undefined These issues are logged in /var/log/Xorg.0.log (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/i915_dri.so failed (/usr/lib/xorg/modules/dri/i915_dri.so: undefined symbol: _glapi_tls_Dispatch) (EE) AIGLX: reverting to software rendering (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (/usr/lib/xorg/modules/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch) (EE) GLX: could not load software renderer (II) GLX: no usable GL providers found for screen 0 Of course, since the driver isn't loaded, nothing works. $ glxgears Error: couldn't get an RGB, Double-buffered visual
It sounds like either the drivers or libGL wasn't built with --enable-glx-tls. Did you build this yourself?
Ah. The version of 10.0.2-1 in the Arch Linux repositories ( https://www.archlinux.org/packages/extra/x86_64/mesa-libgl/ ) Also had this issue. I will try a rebuild now with that flag and see what happens.
To append to the previous comment: I did build it myself after the Arch Linux repositories version also had this issue
Ok. I have now built with the --enable-glx-tls. This does fix the driver loading issue in xorg. However, it creates another issue. Now _glapi_tls_Context is undefined. $ glxgears libGL: OpenDriver: trying /usr/local/lib/dri/i915_dri.so libGL error: dlopen /usr/local/lib/dri/i915_dri.so failed (/usr/local/lib/dri/i915_dri.so: undefined symbol: _glapi_tls_Context) libGL error: unable to load driver: i915_dri.so libGL error: driver pointer missing libGL error: failed to load driver: i915 libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so libGL error: dlopen /usr/local/lib/dri/swrast_dri.so failed (/usr/local/lib/dri/swrast_dri.so: undefined symbol: _glapi_tls_Context) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast While it appears that GL applications appear to be working. This creates some major issues in how GL applications operate. Probably due to my actual driver thats needed to be failing. I'm not sure exactly what driver is being loaded. But I do know the driver I need does still fail to load. And this issue causes major rendering issues in GL powered games.
You're going to need to use something like strace to make sure that the proper libGL is being used.
To be honest I'm not sure why nm insists that the symbol is undefined, despite ldd being silent and objdump explicitly indicating that we link correctly. 1. Check that the symbol is provided via libglapi.so.0.0.0 $ nm -CD --defined-only /usr/lib/libglapi.so.0.0.0 | grep glapi_tls_Context 0000000000000008 B _glapi_tls_Context 2. And libGL.so.1.2.0 is correctly linked $ objdump -x /usr/lib/libGL.so.1.2.0| grep NEEDED | grep libglapi NEEDED libglapi.so.0 3. Ask ldd if it "sees" any undefined symbols $ ldd -r /usr/lib/libGL.so.1.2.0 | grep undefined | wc -l 0 4. On the other hand the dri modules have some (_glapi_* only). This is normal $ ldd -r /usr/lib/xorg/modules/dri/swrast_dri.so | grep undefined undefined symbol: _glapi_tls_Dispatch undefined symbol: _glapi_tls_Context ..... So I'm not really sure what exactly nm means with undefined, and why it does it, yet it tags nearly every imported symbol as U. Give the above commands a try and let us know how it goes. As Matt mentioned strace log would be appreciated as well. $ strace glxinfo Btw I'm running Archlinux on two machines with nouveau_dri.so and i965_dri.so and I've not seen any problems.
As mentioned - issue is likely a misconfigured build. The option will be toggled to enabled shortly. Feel free to reopen, if things persist with --enable-glx-tls
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.