From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/packaging_libpthread.mdwn | 236 ++++++++++++++++++++++++++++++++++ 1 file changed, 236 insertions(+) create mode 100644 open_issues/packaging_libpthread.mdwn (limited to 'open_issues/packaging_libpthread.mdwn') diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..171dc7a0 --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,236 @@ +[[!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. ;-) -- cgit v1.2.3