So, as it turns out GLX_USE_TLS is indeed nothing but an optimization, so can be safely turned off: xsrc/external/mit/MesaLib/dist/docs/dispatch.html This does allow glxgears and several other things to link statically without complaint. However it also turns out that glxgears (and glxinfo) currently still have to be dynamically linked because they insist on loading code at runtime: $ usr/X11R7/bin/glxgears MESA-LOADER: failed to open swrast (search paths /usr/X11R7/lib/modules/dri) libGL error: failed to load driver: swrast X Error of failed request: GLXBadContext Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 27 Current serial number in output stream: 26 This could conceivably be fixed -- perhaps doing so makes binary distributions a little less portable and future-proof (but with the source easily at hand, who cares?). However even when rebuilt dynamically they still don't work for me as they don't seem to be designed to work properly in a true X11 environment: $ usr/X11R7/bin/glxgears libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 26 Current serial number in output stream: 28 $ usr/X11R7/bin/xdriinfo nscreens 1 $ usr/X11R7/bin/xdriinfo driver 1 Screen number "1" out of range. $ usr/X11R7/bin/xdriinfo driver 0 Screen "0" is not direct rendering capable. I.e. they need to be run locally on a system running an X11 server with the appropriate extensions. (Yeah, I know what the "D" in "DRI" stands for, but still it is sad that it is once again no longer true that "The network is the computer" in all too many circumstances -- MESA/OpenGL apps should still work over a network, even if it has to give up on DRI to do so, but I suspect there's no support for this any more.) In any case, there is still toolchain/50277 that's been sitting more or less idle for years now. I also wonder if it is _necessary_ to include _definitions_ for _glapi_tls_Dispatch and _glapi_tls_Context in glxcurrent.c (i.e. as opposed to just declarations so they can properly share the same storage with the instances defined in u_context.c). I'm not knowledgeable enough about all the compiler and linker magic that makes TLS work to know one way or another. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgph8_W1mjJ7C.pgp
Description: OpenPGP Digital Signature