Re: libpthread linking problem -- [address@hidden: Re: imagemagick: convert hangs on hurd-i386]

[Samuel Thibault]

Hi,

Thomas Schwinge, le Fri 26 Jan 2007 14:13:48 +0100, a écrit :
> > Ok, the problem is that convert is linked both with libpthread and
> > libX11, and when looking for the pthread_mutex_unlock() symbol, the one
> > from libX11 (void stub) is found instead of the one from libpthread.
> 
>     19: 000062f0    41 FUNC    WEAK   DEFAULT   10 _pthread_mutex_lock
> 
> Why is `_pthread_mutex_lock' still a weak symbol?

That's odd.  It should really be compiled as a strong symbol, not a weak
one, since source code reads as:

./sysdeps/generic/pt-mutex-lock.c:strong_alias (__pthread_mutex_lock,
_pthread_mutex_lock);


> And why do we need all three of `__NAME', `_NAME' and `NAME'?

__NAME is usually used for letting libpthread be sure to call its own
functions, while NAME can be overriden by other libraries. I don't know
for _NAME.

> > The
> > result is that the inlined version of pthread_mutex_lock() locks the
> > mutex, but pthread_mutex_unlock() doesn't unlock it (since that's X11's
> > one which is called), and this results to a hang as soon as you try to
> > lock a mutex twice. The unfortunate effect is that a bunch of package
> > then FTBFS just because they use convert during their build.
> 
> Does that mean that we need to rebuild X11 now?

Nope.

> Michael once found out that there may be further problems:
> 
> <azeem> dnl XXX incomplete, please fill this in
> <azeem> if test x$xthreads = xyes ; then
> <azeem>     case $host_os in

This got fixed.

> <azeem> because configure.ac doesn't find pthread stubs in libc...
> <azeem> checking for pthread_self in -lc... yes (Linux)
> <azeem> checking for pthread_self in -lc... no (Hurd)

That's fine: libX11 then compiles weak void hooks, which is fine (since
libpthread.so now provide strong aliases, which take precedence).

Samuel