The culprit appears to be in faulty (NULL) resolution of references to pthread methods when invoked from within clib's initialization, the article (above) suggests that not the *all* of [required] libpthread.a objects get included into the static executable by the linker, so we might want to force the inclusion of the *WHOLE* of libpthread.a using -Wl,--whole-archive/-Wl,--no-whole-archive block.
This is exactly what the currently committed fix does - no SIGSEGV at initialization now.
Found a more-or-less relevant case to look at: http:// gcc.gnu. org/bugzilla/ show_bug. cgi?id= 52590 .
The culprit appears to be in faulty (NULL) resolution of references to pthread methods when invoked from within clib's initialization, the article (above) suggests that not the *all* of [required] libpthread.a objects get included into the static executable by the linker, so we might want to force the inclusion of the *WHOLE* of libpthread.a using -Wl,--whole- archive/ -Wl,--no- whole-archive block.
This is exactly what the currently committed fix does - no SIGSEGV at initialization now.
On a more general thread of thought, static linking is often looked down, as seen in this article: www.akkadia. org/drepper/ no_static_ linking. html
http://