I decided I wanted to upgrade my kernel from the 1.5Q one to whatever's
	in current (among other things, I wanted to see if the keyboard sync
	problem has been fixed).

	I sup'ed all of current and proceeded to make build (after upgrading
	make and yacc)

	I ran into two problems, one of which I cannot figure out how to solve.
	I'm aware that current is "not guaranteed to work, or even build", but
	I'm asking about it anyway on the off chance that a) someone will see
	what stupid thing I'm doing or b) something really is broken, but no one
	knows about it

	The first problem happens when building libc:
	building shared c library (version 12.71)
	ld -x -shared -soname libc.so.12 -o libc.so.12.71  /usr/lib/crtbeginS.o 
	--whole
	-archive libc_pic.a --no-whole-archive   /usr/lib/crtendS.o
	libc_pic.a(__posix_rename.so): In function `___posix_rename':
	__posix_rename.so(.text+0x1c): relocation truncated to fit:
	R_SPARC_GOT13 ___cerror
	[more of same...]
	This seems to be caused by /usr/include/sparc64/asm.h being confused
	when it's included by something being run under /usr/bin/cpp, rather
	than gcc -E. since __arch64__ is not defined by the standalone
	preprocessor, _C_LABEL is defined in the pre-ELF (prefix C symbols with
	_) way of doing things. I have worked around this for my build.

You need to install a patch to 1.5 to fix /usr/bin/cpp
or make sure you install the correct shell script to fix
this.

	The second problem happens the first time a program is built. It seems
	that there is something wrong with one or more of the crt*.o files
	instaled into /usr/lib, and most any program built with them segfaults.
	This may have to do with environment setup, but given the unhappy stack,
	I can't tell for sure:
	(gdb) b main
	Breakpoint 1 at 0x1005d0: file foo.c, line 3.
	(gdb) run
	Starting program: /home/cg2v/foo 

	Breakpoint 1, main (argc=0, argv=0xffffffffffffd548, envp=0x7ffffd550)
	    at foo.c:3
	3       printf("I don't care what my arguments are\n");
	(gdb) cont
	Continuing.

	Program received signal SIGSEGV, Segmentation fault.
	0x108d5c in __findenv ()
	(gdb) where
	#0  0x108d5c in __findenv ()

Obviously your `envp' has gotten corrupted and lost the
high bits.  This is probably due to a mis-match between
the kernel and crt0.  Make sure your kernel is newer
than your crt0.o.

This can also have to do with the way the kernel is
setting up the initial stack and crt0 and ld.elf_so
are interpreting the contents.  First, determine if this
occurs with both static and dynamic binaries.  If only the
former, update ld.elf_so.  If the latter, then you need
to instrument crt0 or use gdb to get hex dumps of the
initial stack.

This could also be a sideffect of not having the correct
things defined in cpp.

Eduardo