The way that scsh calls the C fork() routine is to call a related C "stub"
procedure defined by the define-foreign interface. For fork(), the stub
procedure is df_fork(). This stub procedure converts the Scheme args to
C values, calls fork, then converts the result back into a Scheme value
and returns to scsh.
There are basically two possibilities here:
1. The C file defining df_fork() and friends isn't being linked in
to the Scsh vm binary. That means that when scsh tries to find the
address of the routine at runtime, it comes up empty-handed and complains.
2. The routines *are* being linked in, but the lookup is somehow going wrong.
- Maybe the linker flushed (stripped) the information from the binary.
- Maybe the vm wasn't invoked with the right -o argument -- that is
how the lookup is performed.
- Maybe the vm was compiled to lookup symbol "_foo" to find the address
of C function foo(), and the actual symbol is "foo" *or* vice-versa.
It varies from OS to OS. Our configuration technology (when you run
./config prior to the make) tries to figure out what is the case on
your system. (See the file unix.c for more.)
Look at the make transcript to determine the answer to (1). The file
containing df_fork() is scsh/syscalls.c. Is scsh/syscalls.o being
linked into scshvm? Use
nm scshvm | grep fork
to find some of the answers to (2).
For what it's worth, you are the second user reporting a problem with
the HP-UX install, which is weird, because we have n-2 completely problem-free
installs on HP-UX. My group has direct access to HP-UX, and we have no
problems. It's one of the easier installs -- they are very Posix-compliant.