---
hurd/running/nix.mdwn | 3 -
open_issues/libpthread_dlopen.mdwn | 3 -
open_issues/packaging_libpthread.mdwn | 236 --------------------------
open_issues/versioning.mdwn | 19 ---
source_repositories/glibc.mdwn | 2 +-
5 files changed, 1 insertion(+), 262 deletions(-)
delete mode 100644 open_issues/packaging_libpthread.mdwn
diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn
index 66824cf0..5ceb0b8f 100644
--- a/hurd/running/nix.mdwn
+++ b/hurd/running/nix.mdwn
@@ -412,9 +412,6 @@ Nix, and because of that, it uses per-package installation
directories under
folder with the mach headers are installed?
<tschwinge> I wonder whether it'd be better for you to directly include
libpthread in glibc, as Debian is doing -- probably yes.
-
-[[open_issues/packaging_libpthread]].
-
<phant0mas> maybe it would be much simpler that way
<phant0mas> let me check the debian package
<braunr> i'd consider it mandatory, since libpthread can't work correctly
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
<youpi> (ideally)
<youpi> but for this we need to build libpthread along glibc, to get it
really working
-
-[[Packaging_libpthread]].
-
<youpi> and that's the tricky part (Makefile & such) which hasn't been done
yet
<pinotree> 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
-
- <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)
-
-
-# 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> 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
-
-
-## 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-08-07
-
- <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
-
-
-## IRC, OFTC, #debian-hurd, 2013-02-08
-
- <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.
-
-
-# IRC, freenode, #hurd, 2012-11-16
-
- <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
-
-
-# libihash
-
-## IRC, freenode, #hurd, 2012-11-16
-
- <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. ;-)
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]].
-
- <pinotree> once libc is switched internally from cthreads to pthreads (thus
- breaking its BC), may be worth cleanup the hurd-specific exported symbols
- <tschwinge> 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.
- <pochu> 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
diff --git a/source_repositories/glibc.mdwn b/source_repositories/glibc.mdwn
index 85490368..1670c495 100644
--- a/source_repositories/glibc.mdwn
+++ b/source_repositories/glibc.mdwn
@@ -29,7 +29,7 @@ Debian glibc is based on EGLIBC 2.13 and the Savannah
hurd/glibc.git one is
tracking sourceware master.
The Savannah hurd/glibc.git one does not/not yet include
-[[libpthread|open_issues/libpthread]], [[open_issues/packaging_libpthread]].
+libpthread.
# Usage
--
2.53.0
