On Fri, Jan 25, 2019 at 01:16:30PM -0800, Eric Anholt wrote: > Patrick Steinhardt <[email protected]> writes: > > > The musl libc library does not have any support for the > > "initial-exec" TLS model and is unlikely to ever implement it. > > Thus, TLS support in GLX has been turned off in musl-based > > distributions to work around problems when dlopen'ing drivers. > > While this is easily possible using the autoconf build system by > > passing `--disable-glx-tls`, meson does not yet have such an > > option. > > > > Add a new toggle "glx-tls" that defaults to `true` to gain parity > > with autoconf. If disabled, `GLX_USE_TLS` will not be defined and > > thus mesa will be built without TLS support. > > Could you compile-test instead of having an option for people to get > wrong?
Unfortunately, I'm not aware of any easy way to do this. The problem is not due to the compiler, as the program compiles and links just fine with musl libc. Instead, this is a runtime issue that happens when dlopen'ing shared objects with the "initial-exec" TLS model. And as far as I understand, the error only occurs if the PT_TLS segment size of the loaded shared object exceeds the space preallocated for it by the libc. I don't think that testing the above is trivial to do. I certainly wouldn't know how to make meson do the right thing automatically. Regards Patrick
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
