From fb386d00dd580540b022ccf6157c423ff076105e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 30 Jul 2010 16:37:25 +0200 Subject: open_issues/libpthread_weak_symbols: New. --- open_issues/libpthread_weak_symbols.mdwn | 50 ++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 open_issues/libpthread_weak_symbols.mdwn diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!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_libpthread]] + +IRC, unknown channel, unknown date. + + btw, the issue with pthread_cancel is tricky + I'm afraid there might be no fix + clean fix, I mean + oh, hm + where it the problem located, actually? + it's a lot more than just one place + in some c++ header there is a weak reference to pthread_cancel + libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + problem comes when also linking with a library which pulls libpthread + oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + it couldn't implement it anyway + and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + and can't find it + I don't know how this translate to english, but we're “walking on eggs + ” on this issue + i see + i.e. we already know we're not respecting the ELF standard + we need a feature that is not in the standard to make pthread symbols working + the solution would be to integrate libpthread into the glibc + you mean in the sources, but still providing separate libc.so and libpthread.so? + yes + would that be difficult/tricky? + because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + problem is upstream, you know... + if we put libpthread there, it'll be difficult for us to maintain it + ah, the friendly ulrich mate? + we already have difficults to get almost trivial patches commited + and the "yes I'll handle it someday" Roland mate + Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + what we could do is to do it in Debian for the moment + yeah + iirc eglibc is maintained within git, isn't it? + maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + we're already moving to something like that, yes + at least for all the other glibc patches we have + maybe we'll just do that on sourceware actually -- cgit v1.2.3