I did a little more research on this:

On Tue 08 Aug 2000 at 22:56:46 +0200, Olaf Seibert wrote:
> azenomei.3:~/distfiles/mojonation/extsrc/PyXML-0.5.3$ python setup.py build
> 
> Executing 'build' action...
> 
> Running command: make
> cd expat ; make libexpat.a CC="/usr/pkg/pthreads/bin/pgcc" CFLAGS="-fPIC -O2 -I/usr/pkg/include/python1.5 -I/usr/pkg/include/python1.5 -DHAVE_CONFIG_H -Ixmltok -Ixmlparse"
> `libexpat.a' is up to date.
> ranlib expat/libexpat.a
> cc -shared  pyexpat.o  expat/libexpat.a -o pyexpat.so
> collect2: ld terminated with signal 26 [Virtual timer expired]
> *** Error code 1

I could not really believe that the virtual timer signal was *really*
delivered to ld, but a simple ktrace showed that indeed, ld is getting
signalled while only the original python has set the alarm. In between
are several vfork()/exec()s: python -> make -> cc -> collect2 -> ld.

Again, I would not expect a (virtual) timer alarm to remain set across
an exec(). The manpage for setitimer(2) does not discuss this, but it is
nonsensical because the signal handlers are reset as well. So either I
misunderstand this (and then unproven-pthreads must somehow be fixed),
or there is a rather big bug in the kernel (which needs to be fixed). 

Which is it?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert - rhialto@polder    -- Ah only did well at school
\X/ land.nl       -- tae git intae an O level class tae git away fae Begbie.
Hi! I am a .signature virus. Copy me into your .signature to help me spread.