[[!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 My idea was to have a separate libpthread package. What do you think about that? in the long term, that can't work with glibc because of the thread stub stuff [[libpthread_dlopen]], for example. it's not really possible to keep synchronized because you have to decide which package you unpack first (when upgrading) 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? ... for incompatible forward changes? that'd be a mess to maintain Drepper doesn't have this constraint and thus adds members of private fields at will OK, but how is it different then if the libpthread is in the Hurd package? I'm not saying it's better to have libpthread in the Hurd package OK. I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc Then, to goal is to have it in glibc? OK. :-) OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. So our official goal is to have libpthread in glibc, at least for Debian purposese? for any port purpose Ack. provided you're using glibc, you're deemed to ship libpthread with it because of the strong relations Drepper puts between them (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) yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used (would be nice to not have those issues anymore...) 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.) Does that sound about right, or am I missing something fundamental? I actually don't know what a git submodule permits :) looks like a good thing for this, yes Unfortunately I can't allocate much time at the moment to work on this. :-/ well, as long as I know where we're going, I can know how to package stuff in Debian That sounds like a plan to me. libpthread -> glibc as submodule. (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 had you tried to build libpthread as a glibc addon? 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. k I'm trying it atm Oh, OK. that should fix the no-add-needed issue in gcc/binutils, as well as the pthread_threads assertion errors in threaded plugins (once I add forward.c, but that part should not be hard) that means also less use of pthread-stubs^ ? tschwinge: do you remember whether sysdeps/mach/bits/spin* are used by anybody? they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and come in the way when building in glibc pinotree: rid of pthread-stubs yes \o/ youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea about that one, sorry. I'm talking about libpthread not glibc Oh. sysdeps/i386/bits/spin-lock.h:# define __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) Anyway, no idea about that either. that one is meant to be used with the spin-lock.h just below +-inline also, I guess signal/ was for the l4 port? youpi: I guess so. 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 we don't have a non-mach sysdeps directory? youpi: if you add sysdeps/mach/hurd/Implies containing only "hurd", does sysdeps/hurd work? ah, right youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or in libpthread/sysdeps/mach/hurd?) pinotree: it worked, it was for libpthread good: I got libpthread built and forward working ## IRC, freenode, #hurd, 2012-04-23 phew confirmed that moving libpthread to glibc fixes the gcc/binutils no-add-needed issue ## IRC, freenode, #hurd, 2012-08-07 Also, the Savannah hurd/glibc.git one does not/not yet include libpthread. But that could easily be added as a Git submodule. youpi: To put libpthread into glibc it is literally enough to make Savannah hurd/libpthread.git appear at [glibc]/libpthread? tschwinge: there are some patches needed in the rest of the tree see in debian, libpthread_clean.diff, tg-libpthread_depends.diff, unsubmitted-pthread.diff, unsubmitted-pthread_posix_options.diff 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. tschwinge: is there any plan to merge libpthread.git in glibc.git upstream ? braunr, youpi: Has not yet been discussed with Roland, as far as I know. has not libpthread.diff is supposed to be a verbatim copy of the repository and then there are a couple patches which don't (yet) make sense upstream ## IRC, OFTC, #debian-hurd, 2013-02-08 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?). imho a git submodule could be a solution, if glibc people would accept it if so, libpthread.git would need proper glibc/x.y branches to follow glibc Yep. I though that would be the least invasive approach for glibc upstream -- and quite convenient for us, too. after all, git submodules don't track branches, but point to specific commits, no? Correct. So we can do locally/in Debian whatever we want, and every once in a while update the upstream glibc commit ID for libpthread. so we could update the git submodule references in glibc when we've tested enough libpthread changes Just like when committing patches upstream, just without pestering them with all the patches/commits. Yep. # IRC, freenode, #hurd, 2012-11-16 *** $(common-objpfx)resolv/gai_suspend.o: uses /usr/include/i386-gnu/bits/pthread.h so the ones in the libpthread addon are not used... pinotree: The latter at leash should be useful information. tschwinge: i'm afraid i didn't get you :) what are you referring to? 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. tschwinge: ah sure -- basically, the stuff in libpthread/sysdeps/generic are not used at all (glibc only uses generic for glibc/sysdeps/generic) 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 also, libpthread uses hurd's ihash 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. My notes say: * include/inline-hashtab.h * locale/programs/simple-hash.h * misc/hsearch_r.c * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd No idea whether they're equivalent/usable. interesting And no immediate recollection what NNS is; f46f0abfee5a2b34451708f2462a1c3b1701facd is not a glibc commit after all. ;-) Oh, and: libiberty: `hashtab.c` 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 but that shouldn't be an ussue, i guess *issue No that'd be fine. My understanding is that the long-term goal (well, no so long-term, actually) is to completely move libpthread into glibc. ie have it buildable only ad glibc addon? Yes. No need for more than one mechanism for building it, I think. Hmm, this doesn't bring us any further: https://www.google.com/search?q=f46f0abfee5a2b34451708f2462a1c3b1701facd yay for acronyms ;) So, if someone figures out what NNS and this commit it are: one beer. ;-)