<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)
<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
<youpi> phew <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils no-add-needed issue
<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
<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.
<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
<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. ;-)