1 files changed, 84 insertions, 0 deletions
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
new file mode 100644
index 00000000..fb665c67
--- /dev/null
+++ b/open_issues/libpthread_dlopen.mdwn
@@ -0,0 +1,84 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_libpthread]]
+
+IRC, OFTC, #debian-hurd, 2011-07-21.
+
+    <youpi> there's one known issue with pthreads
+    <youpi> you can't dlopen() it
+
+... if the main application is not already linked against it.
+
+    <youpi> which also means you can't dlopen() a module which depends on it if
+      the main application hasn't used -lpthread already
+    <youpi> (so as to get libpthread initialized early, not at the dlopen()
+      call)
+    <lucas> I get this while building simgrid:
+    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
+      /usr/bin/cmake -E create_symlink
+      /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so
+      /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so
+    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
+      lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua
+    <lucas> lua:
+      /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68:
+      __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
+    <lucas> Aborted (core dumped)
+    <youpi> that's it, yes
+    <youpi> (or at least it has the same symptoms)
+    <lucas> it would need fixing in lua, not in SG, then, right?
+    <youpi> yes
+    <lucas> ok, thanks
+
+The fix thus being: link the main application with -lpthread.
+
+IRC, freenode, #hurd, 2011-08-17
+
+    < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but
+      openjade itself is not liked against libpthread
+    < youpi> which means unexpectedly  loading pthreads on the fly, which is
+      not implemented
+    < youpi> (and hard to implement of course)
+    < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread
+    < gnu_srs> Shuoldn't missing linking with pthread create an error when
+      building openjade then?
+    < youpi> no
+    < youpi> because it's just a module which needs pthread
+    < youpi> and that module _is_ linked with -lpthread
+    < youpi> and dlopen() loads libpthreads too due to that
+    < youpi> but that's unexpected, for the libpthread initialization stuff
+    < youpi> (and too late to fix initlaization)
+    < gnu_srs> How come that other OSes build opensp w/o problems?
+    < youpi> because there are stubs in the libc
+    < gnu_srs> Sorry for the delay: What hinders stubs to be present also in
+      the Hurd libc parts too, to cope with this problem?
+    < youpi> doing it
+    < youpi> which is hard because you need libpthread bits inside the libc
+    < youpi> making it simpler would need building libpthread at the same time
+      as libc
+
+[[packaging_libpthread]]
+
+---
+
+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.