From 6f9c0342f33f52a2bda98d3709fbefd678bd46d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 06:06:11 +0200 Subject: IRC. --- open_issues/libpthread.mdwn | 53 +++++++++++++-------------------------------- 1 file changed, 15 insertions(+), 38 deletions(-) (limited to 'open_issues/libpthread.mdwn') diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 614f1271..c5054b7f 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!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 @@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task. [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] +## IRC, freenode, #hurd, 2012-04-26 -# pthread/stubs issue w/ dlopen'ed libraries + youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? -IRC, freenode, #hurd, 2010-01-24 +[[Packaging_libpthread]]. - 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 + it's the same libpthread + symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + i know, i was referring about the clash between actively using + both + there'll still be the issue that only one will be initialized + and one that provides libc thread safety functions, etc. + that's what i wanted to knew, thanks :) -- cgit v1.2.3