bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libpthread & glibc


From: Samuel Thibault
Subject: libpthread & glibc
Date: Mon, 26 Mar 2007 00:32:20 +0200
User-agent: Mutt/1.5.12-2006-07-14

Hi,

Several bugs are triggered (on imagemagick, libstdc++, gettext, ...) by
the fact that on the Hurd, libc.so doesn't provide pthread_mutex_lock &
co POSIX 1c stubs.

The way it is done in GNU/Linux is by making libpthread.so transmit
function addresses to libc.so when it gets loaded, but for this to
properly work, libc and libpthread must be compiled at the same time for
making sure that they agree on the way those functions are passed.

For achieving the same on GNU/Hurd, the Hurd's libpthread needs to be
included in glibc. That shouldn't be so big a work.

In addition to that, proper TLS needs to be implemented in GNU/Hurd's
libpthread.  That should be doable in a dozen lines of code + fixes here
and there.

Now, somebody once suggested to port NPTL to GNU/Hurd.  This wasn't
stupid at all: in principle NPTL can be ported since there is already
a sysdeps/ hierarchy for this.  That would make future maintaining a
lot easier, since the code would then be shared with GNU/Linux.  That
however means a fairly good initial amount of work for doing the port.

So, what's your opinion on this?  We really need to fix both POSIX 1c
stubs and TLS.  Should we

- keep libpthread in Hurd/ and have a risky way to implement POSIX 1c
stubs by passing a "well known" structure, or
- move libpthread into glibc/ and implement the same forward.c as in
nptl, or
- "simply" port NPTL to GNU/Hurd?

Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]