Today I was trying to fix a makefile that's supposed to be highly
portable, and so I thought I'd get a copy of the SunOS-4 sun4 make
binary and using emulation mode see if the makefile was at least still
understood properly by SunOS-4 make.

Unfortunately SunOS-4 make execs /bin/arch (among other things), using
that explicit path.

	20:35 [277] $ /emul/sunos/bin/make -n
	/bin/arch: not found
	make: Fatal error: Execute of /bin/arch failed
	20:35 [278] $ ls -l /emul/sunos/bin
	lrwxr-xr-x  1 root  wheel  7 Oct 22 13:40 /emul/sunos/bin -> usr/bin
	20:36 [279] $ ls -l /emul/sunos/usr/bin
	total 770
	-rwxr-xr-x  1 woods  wheel    1010 Oct 22 13:40 arch
	-rwxr-xr-x  1 woods  wheel   90112 Oct 22 19:27 awk
	-rwxr-xr-x  1 woods  wheel  115472 Oct 22 13:40 make
	-rwxr-xr-x  1 woods  wheel  163840 Oct 22 19:27 nawk
	20:36 [280] $ /emul/sunos/bin/arch       
	unknown

Now since there's no /bin/arch in NetBSD I could put a fake /bin/arch on
my system, or I could get the real SunOS-4 /bin/arch and put a symlink
from /bin/arch to /emul/sunos/bin.

However this raises the question of what to do when you have an emulated
binary that execs a conflicting program *and* depends on the behaviour
of the emulated OS' version of the program.

Is this beyond even the theoretical limits of the /emul system, or might
it be possible to make the exec() wrapper slightly smarter so that it
first tries prefixing the path with "/emul/$os/" first?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>