I have an ultra5 running 1.6.2 with a GENERIC (thus 64-bit) kernel.  I
have been building packages, and mostly things are ok (programs
compile and run).  An example program:

/usr/pkg/bin #> file digest 
digest: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for NetBSD, dynamically linked (uses shared libs), stripped
/usr/pkg/bin #> ldd digest 
digest:
         -lc.12 => /usr/lib/libc.so.12
sunpal5 root 283 /usr/pkg/bin #> 

Two packages failed to build: php4 and ImageMagick.  php4 got an
internal compiler error, and I'm not yet sure what's wrong with
ImageMagick (perhaps not sparc64-specific).  So I am wondering if I
should be doing something different.

My real goals are to have a rock-solid machine to replace an SS20, but
run faster.  64-bit is cool, but that's not very important to me for
this box.

I think my choices are:

a) run 64-bit kernel and 64-bit userland, perhaps with occasional
   32-bit emulation if I didn't want to/couldn't recompile.

b) run 32-bit kernel and 32-bit userland (which I get by installing the
   NetBSD/sparc sets???)

I get the impression that choice b isn't a very good idea, but it may
only be that the emulation in choice a is not completely winning (per
compat_netbsd32(8) - sysctl and IPC), but that the 32-bit kernel is
solid at 32-bit binaries.

I didn't find anything that indicated an easy way to build 32-bit
packages (from pkgsrc) on a 64-bit system.  Can I use build.sh to make
cross-tools and then just run 'nbmake-sparc' in pkgsrc?  (I wouldn't
think so, but I've been amazed before.)

Do I basically have a correct take on the world above?

Is sparc64 such that I should be running current, even if I value
stability over new stuff?  I run current on one notebook, and it's
been pretty stable, but not "cvs update along the branch and kick off
a script that builds/installs kernel and userland and then reboots on
a machine that I'd have to drive 30 minutes to get to" stable.

Or, is gcc 2.95 known to be trouble, and I should try
pkgsrc/lang/gcc3?

Thanks in advance for any clues.

-- 
        Greg Troxel <gdt@ir.bbn.com>