From 0264e7fea77fb52b8575e837b4457c37d3a46378 Mon Sep 17 00:00:00 2001 From: Joshua Branson Date: Thu, 2 Apr 2026 21:22:41 -0400 Subject: delete open_issues/packaging_libpthread.mdwn. Message-ID: <20260403012244.8302-5-jbranso@dismail.de> --- open_issues/libpthread_dlopen.mdwn | 3 - open_issues/packaging_libpthread.mdwn | 236 ---------------------------------- open_issues/versioning.mdwn | 19 --- 3 files changed, 258 deletions(-) delete mode 100644 open_issues/packaging_libpthread.mdwn (limited to 'open_issues') diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 9e127841..1c41ab1a 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -46,9 +46,6 @@ single-threading to multi-threading, which is only supported since libc0.3 (ideally) but for this we need to build libpthread along glibc, to get it really working - -[[Packaging_libpthread]]. - and that's the tricky part (Makefile & such) which hasn't been done yet why both (stubs + actual libpthread)? diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn deleted file mode 100644 index 171dc7a0..00000000 --- a/open_issues/packaging_libpthread.mdwn +++ /dev/null @@ -1,236 +0,0 @@ -[[!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. ;-) diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn index 18fb588e..ca44f61d 100644 --- a/open_issues/versioning.mdwn +++ b/open_issues/versioning.mdwn @@ -51,25 +51,6 @@ versioning? There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` - -### IRC, freenode, #hurd, 2012-12-14 - -[[!tag open_issue_glibc open_issue_libpthread]] - -In context of [[packaging_libpthread]]/[[libpthread]]. - - once libc is switched internally from cthreads to pthreads (thus - breaking its BC), may be worth cleanup the hurd-specific exported symbols - pinotree: Yes. If you already have ideas about what to clean - up, feel free to add a new page or a section on open_issues/glibc. - we're gonna break backwards compatibility in glibc on hurd? that - could be the perfect moment to fix the /dev/fd/N problem without adding - new RPCs, though we'd probably have to break backwards-compatibility in - the exec server IIRC... - -[[glibc#execve_relative_paths]]. - - ### `time_t` -- Unix Epoch vs. 2038 #### IRC, freenode, #hurd, 2013-12-12 -- cgit v1.3.1