On Thu, 19 Mar 1998 09:04:28 +0000 (GMT) 
 Alex Hayward <xelah@ferret.lmh.ox.ac.uk> wrote:

 > Oh, yes.... That happened to me. I can't remember how I fixed it now...
 > Its not the compiler. I think it may have been the linker---try relinking
 > libc.so.12.26 from libc_pic.a using the same command line that the
 > Makefile uses but with the --whole-archive --no-whole-archive pair changed
 > to -Bforcearchive. I think that might have been it....

Better yet, the arm32 linker stuff gets committed to the -current source
tree, so this sort of lossage (which was announced with proper advance
warning on current-users) doesn't happen.

 > You should also be aware that if you build a new ld.so it won't work and
 > the the new vfork (the ___vfork14 systerm call) is *badly* broken on arm32
 > systems. This means that anything which uses it (or, say, system()) causes
 > the machine to lock up completely. You can fix that by changing the vfork
 > line in unistd.h (change the rename from ___vfork14 to ___vfork13).

That is a bad way to "fix" the problem!  If it's _really_ broken, you should
comment out the entire __RENAME() thing altogether!

In any case, how is the new vfork(2) "*badly* broken"?  I never received
any bug reports about it on the arm32... I'm skeptical, esp. considering
that the requisite pmap changes were extremely minor, and indeed, the
function necessary (pmap_activate()) already existed, and was in use my
the machine-dependent fork code.

...and the code has been in the tree for some time now... you'd think lots
of folks would have stumbled on it in this amount of time.

 > Maybe I should start send-pr-ing these things...

You should always send-pr bugs.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939