Comment 3 for bug 965798

Allow me to start a discussion about the motivation of the tls-global path 113_fix_tls.diff
and pls correct me if I am wrong ... ofc.

[1] tls-global implies that all the tls fields are directly exposed to the other library or executable loading the
tls-global exposed library.

[1.1] This is IMHO a very bad idea and API hooks shall expose and control it's access,
which actually is true in this case here (glX .. currentContext ..).

[1.2] AFAIK history of the patch was to fix the use-case of loading libGL by another dynamic library
via dlopen .. etc. This seems to be broken now having a multithreading scenario, like JOGL.

[2] Vanilla Mesa8 does not use tls-global, but uses tls-initial-exec, which works fine w/ JOGL and
other use-cases on ArchLinux and other distributions.

It would be great to understand the original motivation and nature of this patch
and ofc whether the multithreading issue is a tls-global constraint or a bug.
The latter maybe generated by gcc .. but this is just a guess ofc.

In case tls-global is indeed not required at all and maybe even a security or stability risk,
I would vote for removing the offending patch.