I think Matthew Green's X11 R6 binaries were built to include the MIT-SHM
extension support (into the server and libXext).  (I know mine are  (-: )

If anyone runs a program that depends/wants to use that SHM support, it'll
undoubtedly try to grab a shared memory segment via shmget() & friends.  If it
does, it will promptly dump core (SIGSYS - Bad system call) because the
two pre-built "install" kernels weren't built with "options SYSVSHM" defined.

Of course, this begats the question, does the System V Shared Memory segment
stuff work in 1.0, specifically in NetBSD/SPARC 1.0?  I noticed this comment in
/usr/src/sys/arch/pc532/conf/NEWCONF:

#options	SYSVSHM			# System V shared memory; broken

I hope this just means it's broken in the PC532 port ... :-)

And whilel I'm asking, what is happening to it in -current?  I just noticed
that /usr/src/lib/libc/gen no longer contains shmget.c, shmat.c, shmdt.c and
shmctl.c; is all this stuff being overhauled or thrown out completely?
(Adam?  Charles?)

Thanks,

	- Greg

P.S. I am asking because I'm well on my way to having a complete set of MBONE
     tools - I've already a hacked SunOS "sd" and "vat" working (the Multicast
     setsockopt() options in <netinet/in.h> got renumbered, grrrrr), and I'd
     have a working set of "nv" and "vic" native binaries going if this SYSVSHM
     stuff were solid/resolved.  I can build the stuff with "NOSHM" switches
     and the like to turn it all off, but performance is a lot better if it
     were to work properly.  So a definitive answer would be most appreciated!