1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
[[!meta copyright="Copyright © 2011, 2012 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]]
[[!toc]]
# IRC, freenode, #hurd, 2010-01-24
<pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
libraries
<pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
we're the only one with such configuration
<pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it
be it does not set THREADLIBS in the configure.ac switch case?
<youpi> that's expected
<youpi> on linux the libc provides hooks itself, on hurd-i386 it's
pthread-stubs
<pinotree> why not explicitly link to pthread though?
<youpi> because there is no strict need to, for applications that don't
need libpthread
<youpi> the dlopen case is a tricky case that pthread-stubs had not thought
about
<pinotree> hm
<pinotree> what if the pthread stubs would be moved in our glibc?
<youpi> that's what we should do yes
<youpi> (ideally)
<youpi> but for this we need to build libpthread along glibc, to get it
really working
[[Packaging_libpthread]].
<youpi> and that's the tricky part (Makefile & such) which hasn't been done
yet
<pinotree> why both (stubs + actual libpthread)?
<youpi> because you need the stubs to be able to call the actual libpthread
<youpi> as soon libpthread gets dlopened for instance
<youpi> +as
<pinotree> i see
<youpi> (remember that nptl does this if you want to see how)
<youpi> (it's the libc files in nptl/)
<youpi> (and forward.c)
<guillem> also if libpthreads gets integrated with glibc don't we need to
switch the hurd from cthreads then? Which has been the blocker all this
time AFAIR?
<youpi> we don't _need_ to
<guillem> ok
# 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.
|
