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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
[[!meta copyright="Copyright © 2010, 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 open_issue_glibc]]
[[!toc]]
# IRC, freenode, #hurd, 2010-07-31
<tschwinge> My idea was to have a separate libpthread package. What do you
think about that?
<youpi> in the long term, that can't work with glibc
<youpi> because of the thread stub stuff
[[libpthread_dlopen]], for example.
<youpi> it's not really possible to keep synchronized
<youpi> because you have to decide which package you unpack first
<youpi> (when upgrading)
<tschwinge> Hmm, how is that different if two shared libraries are in one
package vs. two packages? It isn't atomic either way? Aren't sonames /
versioned library packages solving that?
<tschwinge> ... for incompatible forward changes?
<youpi> that'd be a mess to maintain
<youpi> Drepper doesn't have this constraint and thus adds members of
private fields at will
<tschwinge> OK, but how is it different then if the libpthread is in the
Hurd package?
<youpi> I'm not saying it's better to have libpthread in the Hurd package
<tschwinge> OK.
<youpi> I'm saying it's useless to package it separately when Drepper makes
everything to have us put it along glibc
<tschwinge> Then, to goal is to have it in glibc?
<tschwinge> OK. :-)
<tschwinge> OK, I can accommodate to that. Isn't not that we'd want to
switch libpthread to something else so quickly.
<tschwinge> So our official goal is to have libpthread in glibc, at least
for Debian purposese?
<youpi> for any port purpose
<tschwinge> Ack.
<youpi> provided you're using glibc, you're deemed to ship libpthread with
it
<youpi> because of the strong relations Drepper puts between them
<youpi> (just to remind: we already have bugs just because our current
libpthread isn't bound enough to glibc: dlopen()ing a library depending
on libpthread doesn't work, for instance)
<pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread
isn't used
<pinotree> (would be nice to not have those issues anymore...)
<tschwinge> So -- what do we need to put it into glibc? We can make
libpthread a Git submodule (or move the code; but it's shared also for
Neal's viengoos, so perhaps the submodule is better?), plus some glibc
make foo, plus some other adaptions (stubs, etc.)
<tschwinge> Does that sound about right, or am I missing something
fundamental?
<youpi> I actually don't know what a git submodule permits :)
<youpi> looks like a good thing for this, yes
<tschwinge> Unfortunately I can't allocate much time at the moment to work
on this. :-/
<youpi> well, as long as I know where we're going, I can know how to
package stuff in Debian
<tschwinge> That sounds like a plan to me. libpthread -> glibc as
submodule.
<youpi> (note: actually, the interface between glibc and the libpthread is
the responsibility of the libpthread: it gives a couple of .c files to be
shipped in libc.so)
# IRC, freenode, #hurd, 2012-04-21
<youpi> had you tried to build libpthread as a glibc addon?
<tschwinge> youpi: No, I only know about libpthread in Hurd build system,
and libpthread stand-alone (with the Auto* stuff that I added), but not
yet as a glibc add-on.
<youpi> k
<youpi> I'm trying it atm
<tschwinge> Oh, OK.
<youpi> that should fix the no-add-needed issue in gcc/binutils, as well as
the pthread_threads assertion errors in threaded plugins
<youpi> (once I add forward.c, but that part should not be hard)
<pinotree> that means also less use of pthread-stubs^
<pinotree> ?
<youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
by anybody?
<youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
come in the way when building in glibc
<youpi> pinotree: rid of pthread-stubs yes
<pinotree> \o/
<tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea
about that one, sorry.
<youpi> I'm talking about libpthread
<youpi> not glibc
<tschwinge> Oh.
<tschwinge> sysdeps/i386/bits/spin-lock.h:# define
__PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
<tschwinge> Anyway, no idea about that either.
<youpi> that one is meant to be used with the spin-lock.h just below
<youpi> +-inline
<youpi> also, I guess signal/ was for the l4 port?
<tschwinge> youpi: I guess so.
<youpi> tschwinge: I have an issue with sysdeps pt files:
sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into
sysdeps/mach/hurd/pt-getspecific.c works
<youpi> we don't have a non-mach sysdeps directory?
<pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only
"hurd", does sysdeps/hurd work?
<youpi> ah, right
<pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or
in libpthread/sysdeps/mach/hurd?)
<youpi> pinotree: it worked, it was for libpthread
<youpi> good: I got libpthread built and forward working
## IRC, freenode, #hurd, 2012-04-23
<youpi> phew
<youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils
no-add-needed issue
## IRC, freenode, #hurd, 2012-08-07
<tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include
libpthread.
<tschwinge> But that could easily be added as a Git submodule.
<tschwinge> youpi: To put libpthread into glibc it is literally enough to
make Savannah hurd/libpthread.git appear at [glibc]/libpthread?
<youpi> tschwinge: there are some patches needed in the rest of the tree
<youpi> see in debian, libpthread_clean.diff, tg-libpthread_depends.diff,
unsubmitted-pthread.diff, unsubmitted-pthread_posix_options.diff
<tschwinge> The libpthread in Debian glibc is
hurd/libpthread.git:b428baaa85c0adca9ef4884c637f289a0ab5e2d6 but with
25260994c812050a5d7addf125cdc90c911ca5c1 »Store self in __thread variable
instead of threadvar« reverted (why?), [...]
..., and 549aba4335946c26f2701c2b43be0e6148d27c09 »Fix libpthread.so symlink«
cherry-picked.
<braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git
upstream ?
<tschwinge> braunr, youpi: Has not yet been discussed with Roland, as far
as I know.
<youpi> has not
<youpi> libpthread.diff is supposed to be a verbatim copy of the repository
<youpi> and then there are a couple patches which don't (yet) make sense
upstream
## IRC, OFTC, #debian-hurd, 2013-02-08
<tschwinge> I also have it on my (never-ending) agenda to add libpthread to
the tschwinge/Roger_Whittaker branch and/or propose it be added upstream
(as a Git submodule?).
<pinotree> imho a git submodule could be a solution, if glibc people would
accept it
<pinotree> if so, libpthread.git would need proper glibc/x.y branches to
follow glibc
<tschwinge> Yep.
<tschwinge> I though that would be the least invasive approach for glibc
upstream -- and quite convenient for us, too.
<pinotree> after all, git submodules don't track branches, but point to
specific commits, no?
<tschwinge> Correct.
<tschwinge> So we can do locally/in Debian whatever we want, and every once
in a while update the upstream glibc commit ID for libpthread.
<pinotree> so we could update the git submodule references in glibc when
we've tested enough libpthread changes
<tschwinge> Just like when committing patches upstream, just without
pestering them with all the patches/commits.
<tschwinge> Yep.
# IRC, freenode, #hurd, 2012-11-16
<pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses
/usr/include/i386-gnu/bits/pthread.h
<pinotree> so the ones in the libpthread addon are not used...
<tschwinge> pinotree: The latter at leash should be useful information.
<pinotree> tschwinge: i'm afraid i didn't get you :) what are you referring
to?
<tschwinge> pinotree: s%leash%least -- what I mean was the it's actually a
real bug that not the in-tree libpthread addon include files are being
used.
<pinotree> tschwinge: ah sure -- basically, the stuff in
libpthread/sysdeps/generic are not used at all
<pinotree> (glibc only uses generic for glibc/sysdeps/generic)
<pinotree> tschwinge: i might have an idea how to fix it: moving the
contents from libpthread/sysdeps/generic to libpthread/sysdeps/pthread,
and that would depend on one of the latest libpthread patches i sent
# libihash
## IRC, freenode, #hurd, 2012-11-16
<pinotree> also, libpthread uses hurd's ihash
<tschwinge> Yes, I already thought a little bit about the ihash thing. I
besically see two options: move ihash into glibc ((probably?) not as a
public interface, though), or have libpthread use of of the hash
implementations that surely are already present in glibc.
<tschwinge> My notes say:
<tschwinge> * include/inline-hashtab.h
<tschwinge> * locale/programs/simple-hash.h
<tschwinge> * misc/hsearch_r.c
<tschwinge> * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd
<tschwinge> No idea whether they're equivalent/usable.
<pinotree> interesting
<tschwinge> And no immediate recollection what NNS is;
f46f0abfee5a2b34451708f2462a1c3b1701facd is not a glibc commit after all.
;-)
<tschwinge> Oh, and: libiberty: `hashtab.c`
<pinotree> hmm, but then you would need to properly ifdef the libpthread
hash usage (iirc only for pthread keys) depending on whether it's in
glibc or standalone
<pinotree> but that shouldn't be an ussue, i guess
<pinotree> *issue
<tschwinge> No that'd be fine.
<tschwinge> My understanding is that the long-term goal (well, no so
long-term, actually) is to completely move libpthread into glibc.
<pinotree> ie have it buildable only ad glibc addon?
<tschwinge> Yes.
<tschwinge> No need for more than one mechanism for building it, I think.
<tschwinge> Hmm, this doesn't bring us any further:
https://www.google.com/search?q=f46f0abfee5a2b34451708f2462a1c3b1701facd
<pinotree> yay for acronyms ;)
<tschwinge> So, if someone figures out what NNS and this commit it are: one
beer. ;-)
|
