bug-hurd
[Top][All Lists]
Advanced

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

Re: imagemagick: convert hangs on hurd-i386


From: Samuel Thibault
Subject: Re: imagemagick: convert hangs on hurd-i386
Date: Sat, 20 Jan 2007 03:02:01 +0100
User-agent: Mutt/1.5.11

reassign 407208 hurd
thanks

Hi,

Samuel Thibault, le Tue 16 Jan 2007 22:16:01 +0100, a écrit :
> convert currently hangs on hurd-i386, which makes apache FTBFS.  We have
> yet to investigate, this bug report is mostly for letting people know
> the issue and remember to fix it.

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

It looks to me a bit odd that libpthread defines only weak aliases for
pthread_mutex_lock, since that makes 

        fprintf(stderr,"%p %p\n",pthread_mutex_lock,pthread_mutex_unlock);

print 0x106d910 0x106d910 when linked with -lX11 -lpthread (bogus), and
print 0x102d2f0 0x102db10 when linked with -lpthread -lX11.

Is there a reason for using weak aliases here?  Linux' libpthread.so
uses strong aliases here.  Here is a patch for doing the same here.

Samuel

Attachment: patch
Description: Text document


reply via email to

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