From eca15103f7627fa8fd51f8b5c88a1a4a59059f39 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 24 Jan 2010 18:09:35 +0100 Subject: open_issues/libpthread: New page. IRC discussion from #hurd, 2010-01-24. --- open_issues/libpthread.mdwn | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 open_issues/libpthread.mdwn (limited to 'open_issues') diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn new file mode 100644 index 00000000..68195758 --- /dev/null +++ b/open_issues/libpthread.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010 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_glibc open_issue_pthread]] + +GSoC project idea: [[community/gsoc/project ideas/pthreads]] + +--- + +`#hurd`, 2010-01-24 + + youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed libraries + currently looks like libstdc++ on hurd links to pthread-stubs, we're the only one with such configuration + i was looking at the gcc 4.4 patch hurd-pthread.diff, could it be it does not set THREADLIBS in the configure.ac switch case? + that's expected + on linux the libc provides hooks itself, on hurd-i386 it's pthread-stubs + why not explicitly link to pthread though? + because there is no strict need to, for applications that don't need libpthread + the dlopen case is a tricky case that pthread-stubs had not thought about + hm + what if the pthread stubs would be moved in our glibc? + that's what we should do yes + (ideally) + but for this we need to build libpthread along glibc, to get it really working + and that's the tricky part (Makefile & such) which hasn't been done yet + why both (stubs + actual libpthread)? + because you need the stubs to be able to call the actual libpthread + as soon libpthread gets dlopened for instance + +as + i see + (remember that nptl does this if you want to see how) + (it's the libc files in nptl/) + (and forward.c) + also if libpthreads gets integrated with glibc don't we need to switch the hurd from cthreads then? Which has been the blocker all this time AFAIR? + we don't _need_ to + ok + -- cgit v1.2.3