[[!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