From 25572bde15a18f44d74b35293b4494f2988c8ff6 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Fri, 19 Aug 2011 15:27:41 +0200 Subject: document that libthreads+libpthread has the same symptom as dlopening libpthread --- open_issues/libpthread_dlopen.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index f60c81a4..0cd761f2 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -14,6 +14,9 @@ IRC, OFTC, #debian-hurd, 2011-07-21. there's one known issue with pthreads you can't dlopen() it + +[ if the main application is not already linked against it ] + which also means you can't dlopen() a module which depends on it if the main application hasn't used -lpthread already (so as to get libpthread initialized early, not at the dlopen() @@ -34,3 +37,20 @@ IRC, OFTC, #debian-hurd, 2011-07-21. it would need fixing in lua, not in SG, then, right? yes ok, thanks + +The fix thus being: link the main application with -lpthread. + +The same symptom appears in an odd case, for instance: + + +buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) +... + +openjade links against *both* libthreads and libpthread. The result is that libc +early-initializes libthreads only, and thus libpthread is not early-initialized, +and later on raises assertions. The solution is to just get rid of libthreads, +to have only one threading library. -- cgit v1.2.3