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
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
