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

[Thomas Schwinge]

Hello!

> 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.

Before applying Samuel's patch:

#v+

    36: 000062f0    41 FUNC    GLOBAL DEFAULT   10 __pthread_mutex_lock
   119: 00006b10   539 FUNC    GLOBAL DEFAULT   10 __pthread_mutex_unlock
    19: 000062f0    41 FUNC    WEAK   DEFAULT   10 _pthread_mutex_lock
    80: 00006b10   539 FUNC    WEAK   DEFAULT   10 _pthread_mutex_unlock
   222: 000062f0    41 FUNC    WEAK   DEFAULT   10 pthread_mutex_lock
   192: 00006b10   539 FUNC    WEAK   DEFAULT   10 pthread_mutex_unlock
#v-

With his patch:

#v+
    36: 000062f0    41 FUNC    GLOBAL DEFAULT   10 __pthread_mutex_lock
   119: 00006b10   539 FUNC    GLOBAL DEFAULT   10 __pthread_mutex_unlock
    19: 000062f0    41 FUNC    WEAK   DEFAULT   10 _pthread_mutex_lock
    80: 00006b10   539 FUNC    GLOBAL DEFAULT   10 _pthread_mutex_unlock
   222: 000062f0    41 FUNC    GLOBAL DEFAULT   10 pthread_mutex_lock
   192: 00006b10   539 FUNC    GLOBAL DEFAULT   10 pthread_mutex_unlock
#v-

Why is `_pthread_mutex_lock' still a weak symbol?  And why do we need all
three of `__NAME', `_NAME' and `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?  Michael once found out
that there may be further problems:

#v+
<azeem> indeed monolithic libX11 had only _pthread_mutex_lock and 
_pthread_mutex_destroy as weak
<azeem> gah, libx11 needs porting
<azeem> dnl XXX incomplete, please fill this in
<azeem> if test x$xthreads = xyes ; then
<azeem>     case $host_os in
<azeem> though the difference is apparently not in linking libX11, but in x11.pc
<azeem> xthreadlib=-lpthread
<azeem> on GNU/Linux
<azeem> xthreadlib=
<azeem> on the Hurd
<azeem>         AC_DEFINE(XUSE_MTSAFE_API,[],[Whether libX11 needs to use MT 
safe API's])
<azeem> we do not define that
<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)
<azeem> other than that, "thread" is not mentioned in the rest of the build log
<azeem> probably we should rebuild on both platforms and inspect the Makefiles
<azeem>  /* Use multi-threaded libc functions? */
<azeem> #define XUSE_MTSAFE_API
<azeem> broken.
<azeem> I don't see XUSE_MTSAFE_API getting used a lot in the libX11 source 
either, though (other than in that public header)
<azeem> the XUSE_MTSAFE_API stuff should be fine
#v-


Regards,
 Thomas

signature.asc
Description: Digital signature