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

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.



Reply to: