When libpthread is dynamically loaded into a static executable the reference to _rtld_global is resolved to the instance in the (just loaded) ld.so, but when the libpthread initializer is run nothing has initialized _rtld_global yet. This causes __pthread_initialize_minimal to crash when calling GL(dl_error_catch_tsd).
Is this something we want to support? I'm asking because it prevents quite a few potential optimizations on statically-linked binaries once link against libdl because we would have to assume that they can turn multi-threaded even if the main executable does not link against libpthread.
As long as we support nss modules.
In our current implementation, NSS modules should never link against libpthread because NSS modules have to minimize the set of libraries and symbols they pull in (see bug 16881). (I'm not saying this isn't a bug, but I'm just trying to put it into perspective.)
libnss_sss uses mutex functions that aren't in libc.
Hi, all I think this bug is not just about nss, it's more serious. A shared library dlopened by static executables could depend on libpthread. The writer of this shared library did nothing wrong, neither did the user of the library（who dlopen the library in a static executable）. But the final program just can not act as expected because of this bug. Generally speaking, the dlopened shared libraries and the static executable should be isolated from each other. The main executable use dlsym to access the functions provided by the shared libraries. Glibc currently support this usage, so we should try to make things right. In fact, there have been dl-static.c which provided a standard way to initialize variables in the dynamic linker ld.so. Unfortunately, this file currently just initialize the dl_pagesize. More over, many main stream architectures(such as arm/x86) did not even implement this file. To fix this bug , I have unified dl-static.c, and added some lines to initialize GL(dl_error_catch_tsd). See the attached patch for more details. Hope this local fix could go upstream.
Created attachment 10079 [details] patch to fix the bug
(In reply to ma.jiang from comment #6) > Created attachment 10079 [details] > patch to fix the bug Patches should be sent to the mailing list. Current master no longer has dl_error_catch_tsd, as part of the fix for bug 16628. Do you have a test case? Maybe this bug has been fixed as well?
(In reply to Florian Weimer from comment #7) Hi, Thanks for your quick reply. > Patches should be sent to the mailing list. Current master no longer has > dl_error_catch_tsd, as part of the fix for bug 16628. > Do you have a test case? Maybe this bug has been fixed as well? Yes, you are right, After the fix in "https://sourceware.org/git/?p=glibc.git;a=commit;h=9e78f6f6e7134a5f299cc8de77370218f8019237" applied. This bug should be gone. Currently, I'm using glibc-2.24 and I just checked the dl-static.c in the trunk... Sorry for this miss. But, I think the main part of this patch(a unified dl-static.c) still should be applied. Anyway,We should initialize variables in ld.so when the main executable is static linked(and dlopen some shared libraries). Currently, I cannot post mail to the mailing list as there were some problems in our email system... I'll post the patch later after our email system get fixed.