There is no need to worry about if its called vfork or __vfork14. The
right one will get built. As vfork is not used internally don't worry
about creating a syscall wrapper.
While I'm here remove a completely unnecessary unistd.h that's looks as
though it was for a early version linux.
out of date - it was based on a.out OBJECT_FMT, and added entries in the
generated PLISTs to reflect the symlinks that ELF packages uses. It also
tried to be clever, and removed and recreated any symbolic links that were
created, which has resulted in some fun, especially with packages which
use dlopen(3) to load modules. Some recent changes to our ld.so to bring
it more into line with other Operating Systems also exposed some cracks.
+ Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain
the ELF symlinks.
+ Don't mess about with file system entries when handling shared objects in
bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will
have got it right, and have a much better idea than we do.
+ Modify PLISTs to contain "ELF symlinks"
+ On a.out platforms, delete any "ELF symlinks" from the generated PLISTs
+ On ELF platforms, no extra processing needs to be done in bsd.pkg.mk
+ Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on
a.out platforms
+ Update the documentation in Packages.txt
With many thanks to Thomas Klausner for keeping me honest with this.
Why am I using MIT-Pthreads? Because all the alternatives seem to have
very low level problems. PTL2 has a locking problem of some sort that I
cannot track down, and the author insists that
lock = PTHREAD_MUTEX_INIT;
is always to be legal, so he uses a pointer for locks. This means
pthread_lock() can break in out of memory situations, and therefore so
can pthread_once(), and if you're using that to protect logging, and you
need to report a memory depletion, you're screwed.
--Michael
