加载插件时出现"cannot allocate memory in static TLS block"问题求助
一、错误成因：静态TLS空间不足
Linux下线程本地存储（TLS）分为两种核心实现模型：
- 静态TLS（Static TLS）：进程启动时预分配一块固定大小的内存区域，用于存放所有加载的共享库中用
__thread声明的全局/静态变量（GCC默认采用initial-exec或local-exec模型）。这块区域的大小在进程启动时就已确定，运行时无法扩展。 - 动态TLS（Dynamic TLS）：通过运行时动态分配TLS空间，无需占用进程初始预留的静态TLS区域，专门适配动态加载的共享库场景。
你的问题本质是：
libother.so使用了静态TLS模型，且它的TLS占用空间较大；- 当
dlopen动态加载libplugin.so时，libother.so作为依赖被延迟加载，此时进程初始的静态TLS区域已无剩余空间容纳它的TLS需求，因此触发cannot allocate memory in static TLS block错误； - 直接链接
libother.so时，进程启动阶段会扫描所有直接依赖库的静态TLS需求，提前预留足够的初始空间，因此不会报错。
二、LD_PRELOAD临时方案的生效原理
LD_PRELOAD会强制指定的共享库在进程启动时就被加载，此时libother.so的静态TLS需求会被纳入进程初始静态TLS区域的计算中，系统会预留足够空间。后续dlopen加载libplugin.so时，libother.so已经存在于进程地址空间，无需再分配静态TLS空间，自然不会触发错误。
三、为何仅该库需要特殊处理
其他插件的依赖库满足以下任一条件：
- 使用了动态TLS模型（编译器默认或显式指定了动态TLS选项），无需占用初始静态TLS空间；
- 静态TLS占用空间较小，进程初始预留的静态TLS区域仍有剩余空间容纳；
- 依赖的库在进程启动时已被加载（比如主程序直接链接），其TLS需求已被提前计算。
而libother.so的静态TLS占用超出了进程初始预留空间的剩余量，且仅在动态加载时才被引入，因此才会触发唯一的错误。
四、dlopen参数的影响
你使用的RTLD_LOCAL | RTLD_LAZY参数与本次错误无直接关联：
RTLD_LOCAL仅控制插件符号的可见范围，不影响TLS空间分配；RTLD_LAZY控制符号延迟绑定，同样不涉及TLS的内存分配逻辑。
即使修改为RTLD_GLOBAL或RTLD_NOW，也无法解决静态TLS空间不足的问题。
五、构建阶段的解决方案（无需修改主程序环境）
方案1：修改libother.so的编译选项，启用动态TLS
在编译libother.so时，添加GCC编译选项：
-ftls-model=global-dynamic
该选项会强制编译器使用动态TLS模型，让libother.so的TLS变量在运行时动态分配空间，不再占用进程初始的静态TLS区域。重新编译libother.so后，dlopen加载libplugin.so时将不会触发错误。
如果libother.so中的TLS变量仅在库内部使用，也可以使用-ftls-model=local-dynamic，进一步优化TLS访问性能。
方案2：静态链接libother.so到libplugin.so
如果libother.so提供静态库版本（libother.a），可以在构建libplugin.so时，将libother.a静态链接进去：
g++ -fPIC -shared -o libplugin.so plugin.o -Wl,--whole-archive libother.a -Wl,--no-whole-archive
静态链接后，libother.so的TLS变量会被合并到libplugin.so中，其TLS需求会在libplugin.so被dlopen时以动态TLS方式分配（因为libplugin.so是动态加载的，编译器默认会为其使用动态TLS模型），从而绕过静态TLS空间不足的问题。
方案3：修改libplugin.so的链接选项，强制动态TLS依赖
如果无法修改libother.so的源码或编译选项，可以在构建libplugin.so时，添加以下链接选项，强制它以动态TLS方式访问libother.so的TLS变量：
-Wl,-z,tls-model=global-dynamic
该选项会告诉链接器，libplugin.so对所有TLS变量的访问都使用动态TLS模型，即使依赖库使用静态TLS，也会转为动态方式处理。
内容的提问来源于stack exchange，提问作者Nicolò Tosi
