| Summary: | _glapi_tls_Dispatch undefined | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | samrg472 |
| Component: | Drivers/DRI/i915 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | blocker | ||
| Priority: | medium | CC: | samrg472 |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
samrg472
2014-01-18 22:42:10 UTC
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.