diff options
Diffstat (limited to 'open_issues/libpthread.mdwn')
| -rw-r--r-- | open_issues/libpthread.mdwn | 51 |
1 files changed, 37 insertions, 14 deletions
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 16b6d098..614f1271 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -10,26 +10,48 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_libpthread]] -GSoC project idea: [[community/gsoc/project ideas/pthreads]] +[[!toc]] ---- -`#hurd`, 2010-01-24 +# cthreads -> pthreads - <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed libraries - <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, we're the only one with such configuration - <pinotree> 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? +Get rid of cthreads; switch to pthreads. + +There is a [[!FF_project 275]][[!tag bounty]] on this task. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] + + + +# pthread/stubs issue w/ dlopen'ed libraries + +IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> 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? <youpi> that's expected - <youpi> on linux the libc provides hooks itself, on hurd-i386 it's pthread-stubs + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs <pinotree> why not explicitly link to pthread though? - <youpi> because there is no strict need to, for applications that don't need libpthread - <youpi> the dlopen case is a tricky case that pthread-stubs had not thought about + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about <pinotree> hm <pinotree> what if the pthread stubs would be moved in our glibc? <youpi> that's what we should do yes <youpi> (ideally) - <youpi> but for this we need to build libpthread along glibc, to get it really working - <youpi> and that's the tricky part (Makefile & such) which hasn't been done yet + <youpi> but for this we need to build libpthread along glibc, to get it + really working + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet <pinotree> why both (stubs + actual libpthread)? <youpi> because you need the stubs to be able to call the actual libpthread <youpi> as soon libpthread gets dlopened for instance @@ -38,7 +60,8 @@ GSoC project idea: [[community/gsoc/project ideas/pthreads]] <youpi> (remember that nptl does this if you want to see how) <youpi> (it's the libc files in nptl/) <youpi> (and forward.c) - <guillem> 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? + <guillem> 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? <youpi> we don't _need_ to <guillem> ok - |