Hey, all. I'm working on a linter based on dylint and I'm getting this error while trying to run dylint:
Failed to load library $TARGET/release/lib$NAME@nightly-2025-08-07-x86_64-unknown-linux-gnu.so: $HOME/.rustup/toolchains/nightly-2025-08-07-x86_64-unknown-linux-gnu/lib/librustc_driver-12dbd1970610030b.so: cannot allocate memory in static TLS block
Running readelf -Wl .../librustc_driver-12dbd1970610030b.so shows that this SO by itself is trying to allocate 8.6 KiB of TLS, which if my understanding that the limit on Linux is 2 KiB, would be simply wrong. Am I missing something or is this build of rustc_driver simply broken? Is there any way I can work around this?
For performance reasons librustc_driver.so is compiled with the initial-exec tls model, which means that it must be an (in)direct dependency of the main executable. It can't be loaded through dlopen. (If it is a dependency of a dlopened dylib, but was already loaded through a dependency of the main executable, that will work just fine however)
Glibc doesn't limit the size of TLS to 2KiB. Rather glibc when doing the initial dynamic linking for the executable which loads all dylib dependencies that don't go through dlopen, glibc will allocate a bit more static TLS space that strictly necessary just in case you want to dlopen a dylib compiled with the initial-exec tls model. If that extra bit of space runs out you get cannot allocate memory in static TLS block. You shouldn't depend on this extra space existing at all though.
Is the executable that uses libloading linked against librustc_driver.so itself? If not try doing that. librustc_driver.so can't be loaded using dlopen due to using the initial-exec tls model.
#![feature(rustc_private)] extern crate rustc_driver; at the top of your main.rs while making sure to compile your executable with the exact same nightly as the plugin you want to dlopen.