[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
[[!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
[[!tag open_issue_libpthread open_issue_glibc]]
# 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
<youpi> I'm not saying it's better to have libpthread in the Hurd package
<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
<youpi> provided you're using glibc, you're deemed to ship libpthread with
<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
<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
<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
<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> 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^
<youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
<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
<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> 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> 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
<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
<youpi> pinotree: it worked, it was for libpthread
<youpi> good: I got libpthread built and forward working
## IRC, freenode, #hurd, 2012-04-23
<youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils
## IRC, freenode, #hurd, 2012-04-27
<pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in
<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
## IRC, freenode, #hurd, 2012-07-21
<pinotree> tschwinge: btw, samuel suggested to rename in libpthread ia32 →
i386, to better fit with glibc
<tschwinge> pinotree: Hmm, that'd somewhat break interopability with
Viengoos' use of libpthread.
<pinotree> how would it break with viengoos?
<tschwinge> I assume it is using the i386 names. Hmm, no isn't it x86_64
<tschwinge> I'll check.
<pinotree> does it use automake (with the Makefile.am in repo)?
<tschwinge> I have no idea what the current branch arrangement is.
<pinotree> tschwinge: it looks like ia32 is hardcoded in Makefile and
## IRC, freenode, #hurd, 2012-08-07
<tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include
<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,
<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 the following additional
change applied to Makefile:
<tschwinge> ifeq ($(IN_GLIBC),yes)
<tschwinge> - ln -sf $(slibdir)/libpthread.so$(libpthread.so-version)
<tschwinge> + ln -sf libpthread.so$(libpthread.so-version) $@
<braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git
<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
<youpi> the slibdir change, however, is odd
<youpi> it must be a leftover