https://sourceware.org/bugzilla/show_bug.cgi?id=14898
https://github.com/dyninst/dyninst/issues/101
https://bugzilla.redhat.com/show_bug.cgi?id=89692
If shared library declease a single TLS global variable of size 1 (one) byte, and this TLS variable is accessed by the binary linking against it the shared library doesnt get loaded because there is an error creating the static TLS block. The attached test case shows both the failed and expected behavior. Untar the files from the tar ball. To reproduce the bug please compile the shared library as follows: libfoo: gcc -g -Wall -Wextra -fPIC -pthread -shared -DBUG -o libfoo.so foo.c test: gcc -g -Wall -Wextra -DBUG -o test test.c -Wl,-rpath . -L . -lfoo $ ./test ./test: error while loading shared libraries: ./libfoo.so: cannot allocate memory in static TLS block To get the expected behavior recompile the tests as follows libfoo: gcc -g -Wall -Wextra -fPIC -pthread -shared -o libfoo.so foo.c test: gcc -g -Wall -Wextra -o test test.c -Wl,-rpath . -L . -lfoo $ ./test foo: 1 address of foo: 0x7f3d359c56fe The behavior is same if the library is compiled without -pthread. I have tested this bug in my system running Ubuntu precise using eglibc-2.15.
-----------------------------------------------------------------------------------------------------------------------------------------------
Just for reference, the fix was to adjust the internal constant not to be the same value as a small sized static TLS image. A workaround is always to increase the size of the TLS storage.