> You need to run the SVR4_MAKEDEV in /usr/src/etc/etc.svr4. It will build 
> the necesarry devices. I have run a few Solaris 2.4 binaries, without too 
> much trouble.

Great !

> Eh, xlock I am not so sure about, but xclock works.

Oops, I meant xclock.
So, now xclock works !
But of course, as soon as I tried something else, it's not quite as convincing:
- less as well as MH's scan doesn't output the CRs (only the LFs) which 
  makes for unreadbale output. Any idea how to solve this problem ?
  Of course tons of other such programs show the same behavior (gdb, ...)
s- emacs running without X has trouble executing the startup files (site-init
  and ~/.emacs), even though "M-x load-file ~/.emacs" after startup works fine.
- emacs running with X exits immediately with error code 22.
  The trace always ends with something like:

 17345 emacs-19.29 PSIG  SIGALRM caught handler=0x434bfb4 mask=0x0 code=0x0
 17345 emacs-19.29 RET   read 1566/0x61e
 17345 emacs-19.29 CALL  ioctl(0x4,FIONREAD,0xf7fdc4cc)
 17345 emacs-19.29 RET   ioctl 0
 17345 emacs-19.29 CALL  sigaction(0xe,0xf7ffd698,0x16d05c)
 17345 emacs-19.29 RET   sigaction 0
 17345 emacs-19.29 CALL  alarm(0x2)
 17345 emacs-19.29 RET   alarm 0
 17345 emacs-19.29 CALL  context(0x1,0xf7ffd930)
 17345 emacs-19.29 RET   context -1 errno 22 Invalid argument
 17345 emacs-19.29 CALL  context(0x1,0xf7ffd930)
 17345 emacs-19.29 RET   context -1 errno 22 Invalid argument
 17345 emacs-19.29 CALL  exit(0x16)

- for some reason access to usr/lib/libdl.so.1 is not reliable (it's NFS mounted
  from a Solaris-2.4 machine). I sometimes get the error:
	ld.so.1: /logiciels/distribution/public/X11R5/sun4-5.2/bin/xterm: fatal: /usr/lib/libdl.so.1: corrupt or truncated file
	Killed
  This error shows up only from time to time with xclock, but always showed up
  with xterm (and never showed up with emacs). I haven't tried it with a local
  copy because the NFS mount is used for so many other files (like the terminfo
  database, which I believe is not available in NetBSD).
 
- xclock sometimes crashes with a segmentation fault. Sadly I can't use the
  core file since gdb doesn't understand Solaris's executable format and
  Solaris's gdb doesn't understand NetBSD's /proc format. And the trace
  isn't too helpful either:

 17386 xclock   NAMI  "/emul/svr4/usr/lib/libresolv.so.1"
 17386 xclock   NAMI  "/emul/svr4"
 17386 xclock   NAMI  "/emul/svr4/usr/lib/libresolv.so.1"
 17386 xclock   RET   open 3
 17386 xclock   CALL  fstat(0x3,0xf7ffe740)
 17386 xclock   RET   fstat 0
 17386 xclock   CALL  mmap(0,0x1000,0x1,0x80000001,0x3,0)
 17386 xclock   RET   mmap 67244032/0x4021000
 17386 xclock   CALL  mmap(0,0x16000,0x5,0x80000001,0x3,0)
 17386 xclock   RET   mmap 70328320/0x4312000
 17386 xclock   CALL  munmap(0x4312000,0x16000)
 17386 xclock   RET   munmap 0
 17386 xclock   CALL  mmap(0,0x26000,0x5,0x80000001,0x3,0)
 17386 xclock   RET   mmap 70328320/0x4312000
 17386 xclock   CALL  munmap(0x4312000,0xe000)
 17386 xclock   RET   munmap 0
 17386 xclock   CALL  mmap(0x4320000,0x5851,0x5,0x80000012,0x3,0)
 17386 xclock   RET   mmap 70385664/0x4320000
 17386 xclock   CALL  munmap(0x4326000,0xf000)
 17386 xclock   RET   munmap 0
 17386 xclock   CALL  mmap(0x4335000,0xaa8,0x7,0x80000012,0x3,0x5000)
 17386 xclock   RET   mmap 70471680/0x4335000
 17386 xclock   CALL  munmap(0x4336000,0x2000)
 17386 xclock   RET   munmap 0
 17386 xclock   PSIG  SIGSEGV SIG_DFL
 17386 xclock   NAMI  "xclock.core"

  since it seems related to dynamic loading, maybe it's related to the previous
  libdl.so.1 problem ?


	Stefan