On 19 February 2018 at 18:40, Alexander von Gluck IV
> February 19, 2018 12:25 PM, "Alexander von Gluck IV" <kallis...@unixzen.com>
>> meson.build | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> diff --git a/meson.build b/meson.build
>> index 6fc7ec7fc9..54572a5bb8 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -331,7 +331,6 @@ if with_egl and not (with_platform_drm or
>> -pre_args += '-DGLX_USE_TLS'
>> if with_glx != 'disabled'
>> if not (with_platform_x11 and with_any_opengl)
>> if with_glx == 'auto'
>> @@ -365,6 +364,10 @@ if with_glvnd
>> +if with_glx != 'disabled'
>> + pre_args += '-DGLX_USE_TLS'
>> # TODO: toggle for this
>> with_glx_direct = true
> Some comments on this one. I was seeing problems loading static TLS binaries
> on Haiku, turns out GLX_USE_TLS impacts more than just GLX. I'm guessing our
> (non-glx) libGL.so is getting it via libglapi linkages.
> Thanks to Dylan for figuring this one out.
> This was discussed previously on the ML
> This can be applied to all GLX implementations, and in autotools this is
> guarded only by the --enable-glx-tls flag. Since this is on by default
> in autotools, and is strictly better than being off, the meson build
> doesn't even have a toggle for it.
> Since the GLX_USE_TLS reaches beyond GLX, i'm guarding it with_glx after
> the glx auto-detection tri-state (which can disable it)
Note: the GLX in the name is for historical purposes - toggle applies
to glapi and the way one (GLX, EGL and DRI modules in particular)
makes use of it.
That said - we had serious issues with people tinkering with the
toggle, so Dylan's decision of omit it is spot on.
For Haiku, I would suggest the following:
- open a bug/other issue about the missing static TLS support
- set the macro for non-haiku platforms, with a clear reference to
the above report.
> I noticed under Fedora the Meson-built libGL differs from the system's
> in terms of TLS.. not sure if relevant (or an issue)
There are a few features missing from the Meson build so I wouldn't be
For now I'd call it a non-issue ;-)
mesa-dev mailing list