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
|
[[!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> also, any reason for using ia32 and not i386? glibc uses the latter
<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/ia32/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-04-27
<pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in
libpthread?
<pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable
for it, and glibc expects i386
<youpi> I know, I've asked tschwinge about it
<youpi> it's not urging anyway
<pinotree> right
|
