Re: Bug#578320: dot fails with assertion on hurd-i386
Samuel Thibault wrote:
> Hello,
>
> David Claughton, le Sun 18 Apr 2010 23:47:06 +0100, a écrit :
>> > Packages that use doxygen to generate documentation FTBFS on hurd-i386
>> > due to the dot binary bailing out due to a pthread asertion:
>> >
>> > dot: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
>>
>> I've received the above bug report concerning the Hurd port.
>
> Ah, sorry that somebody actually pointed that at you. This is a bug in
> hurd's libpthread and has nothing to do with graphviz doing anything
> bad.
>
No problem - do you want me to reassign it? Problem is I don't know
which package - libpthreads-stub0? libc0.3? hurd-dev? Feel free to take
it if you like.
>> Google appears to be telling me this error is some sort of a conflict
>> between cthreads and pthreads, but all the references I can find are
>> quite old - typically around 2005, so I'm not sure if this information
>> is still accurate. graphviz uses -pthreads when linking, so perhaps the
>> problem is that one of it's dependencies doesn't?
>
> In my memory, we had found out that this can happen when an application
> dlopen()s a library (e.g. a plugin) which depends on libpthread, i.e.
> dynamically loads libpthread after libc initialization, which the
> current hurd libpthread is not ready for.
>
> One workaround is to link the application itself with -pthread, but we
> really need to fix it more generally, as quite a few packages have the
> same issue.
Well graphviz certainly does dlopen plugins, but AFAICT everything gets
compiled and linked with -pthread already.
Nevertheless if you end up with a workaround I'll be happy to apply it.
Cheers,
David.
Reply to: