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

 > The machine just stops. (I mean badly in terms of results, not in terms of
 > source code, since I haven't looked at the source code and probably
 > wouldn't get far if I did...). The first I noticed was after installing a
 > new libc in which system called the new vfork. Thereafter man caused the
 > system to hang.

Did you just install a new library and then it started to lose?  The whole
point of naming the call __vfork14() (and using the symbol renaming hack)
was so that in order to use it, programs would have to be recompiled and
relinked before they got the address space sharing semantics (otherwise, they
fell back on the old 4.4BSD vfork(), which only blocks the parent; no
shared address space, no VM changes in the code path).  This was to prevent
those programs which used vfork() unsafely (due to the broken 4.4BSD vfork()
semantics) from losing.

Ah, but man(1) probably calls system(3).  Do things like make(1) work if
they're linked against __vfork14()?

 > But I'm always afraid I've done something silly in the build process...
 > Especially since this is the first time I've built any significant part of
 > -current (except for the kernel). I suppose I was looking for confirmation
 > first. OK, I'll check for anything obviously stupid and check its still
 > there in the latest sup and send-pr it...

...and read current-users.  I _strongly_ suggest that ANYONE running
-current read current-users.  Also, people should get on netbsd-bugs
and netbsd-users...

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