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?
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?
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
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19225 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB