summaryrefslogtreecommitdiff
path: root/open_issues/packaging_libpthread.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/packaging_libpthread.mdwn')
-rw-r--r--open_issues/packaging_libpthread.mdwn125
1 files changed, 107 insertions, 18 deletions
diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index fa3d4312..d243aaaa 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -10,9 +11,13 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_libpthread open_issue_glibc]]
-IRC, #hurd, 2010-07-31
+[[!toc]]
- <tschwinge> My idea was to have a separate libpthread package. What do you think about that?
+
+# 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
@@ -21,30 +26,114 @@ IRC, #hurd, 2010-07-31
<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> 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> 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
+ <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?
+ <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> 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
+ <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?
+ <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)
+ <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