On 9/28/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
No, it looks to me like monotone is running a command during the build that
takes an unreasonably long time to complete on a number of our
architectures.
We could ask the buildd maintainers to increase timeouts for monotone, but
given that the timeout is happening when executing a runtime command that's
*part* of the package, I do have to wonder whether the resulting binaries
are actually useful if they're this slow.
It appears the problem is not a command taking too long run, but a
thread deadlock situation. See below.
Cheers,
Shaun
On 9/28/06, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
I debugged the problem a bit and the problem seems to be the
BOOST_SP_DISABLE_THREADS define and monotone being linked against the
multithreaded boost libraries. boost and monotone have a different idea
of the sp_counted_base class, so that it gets initialized within monotone
non-threaded and boost later tries to lock some initialized memory and
thus hangs.
I recompiled monotone without the two boost defines and it seems to work
fine.
BTW when you generate a diff, please don't forget to touch Makefile.in
somewhere, so the buildd won't attempt to regenerate it again from
Makefile.am.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
