dlopen: cannot load any more object with static TLS

[dlangBugzillaToGithub]

Timothee Cour (@timotheecour) reported this on 2017-01-05T18:21:01Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=17061

CC List

• Timothee Cour

Description

pseudo-code:

```
main.cpp:
dlopen(dlib.so)
dlsym(fun)

dlib.d:
fun(){
  dlopen(dlib2.so);
  // dlopen: cannot load any more object with static TLS
}

dlib2.d:
void fun2(){}
```

Is there a workaround?

[dlangBugzillaToGithub]

timothee.cour2 commented on 2017-01-05T18:36:37Z

found workaround here in a different context:

http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-with-static-tls/36769074#36769074

the workaround is to add `LD_PRELOAD=dlib2.so` before calling the binary

LD_PRELOAD=dlib2.so main

Is there anything better?

[dlangBugzillaToGithub]

timothee.cour2 commented on 2017-01-05T19:34:19Z

obviously LD_PRELOAD trick doesn't work if the lib2.so needs to be recompiled while code is running;

LINKS:
http://stackoverflow.com/questions/22983986/is-there-a-way-to-determine-thread-local-storage-model-used-by-a-library-on-linu
https://lists.freebsd.org/pipermail/freebsd-arch/2016-February/017699.html
https://gcc.gnu.org/ml/gcc-help/2007-08/msg00014.html
https://www.cygwin.com/ml/libc-help/2013-11/msg00033.html

1) Rebuild glibc with more default static TLS storage. e.g. Increase DTV_SURPLUS until it works.

2) Rebuild your dependent libraries so that they don't use initial-exec
TLS model. It's a good optimization but it makes those DSOs unloadable
when you run out of surplus slots to load them into (and no you can't
expand the number of slots because of the way initial-exec optimizes
the TLS accesses).

How would we do option 2?

SCRATCH:
-ftls-model=initial-exec