hi folks.


perry pointed out to me that sparc/sparc64 are not the only platforms
that have this problem.  compat/netbsd32 already has been ported to
x86_64, and at least mips64 and ppc64 ports could arrive in the future,
so a /usr/lib & /usr/lib/sparcv9 solution seems to be less `pure',
particularly from a netbsd perspective.

what do we want to do?  suggestions off the top of my head (i have no
real attachment to any of these ideas):

	32 bit		64 bit
	/usr/lib32	/usr/lib	[*]
	/usr/lib	/usr/lib64
	/usr/lib	/usr/lib/64

for [*], while it provides backwards compatibility for NetBSD/sparc64,
it doesn't truly allow proper sharing of binaries between the 32 bit
and 64 bit platforms.  does it matter if we require people move their
libraries around and cause old programs to probably fail?


also, there's the problem of ld.elf_so:

	/usr/libexec/ld.elf_so32	/usr/libexec/ld.elf_so
	/usr/libexec/ld.elf_so		/usr/libexec/ld.elf_so64
	/usr/libexec/ld.elf_so		/usr/libexec/64/ld.elf_so


(see above about programs failing.)


it's unfortunate that no one realised this would be an issue until
recently, but perhaps we can fix it now, only really breaking users
of netbsd/sparc64 1.5*.


also, it can be that the switch can be done in stages, that would
avoid lossage as long as programs can be relinked at some stage:


	- copy libraries from /usr/lib to (say) /usr/lib64

	- copy ld.elf_so from /usr/libexec to /usr/libexec/ld.elf_so64

	- rebuild/reinstall the entire system

	- relink any 3rd party applications

	- maybe install 32 bit libraries into /usr/lib


the last step is what will break existing software, and it can be
left out (which will of course mean no 32 bit support.)


what do people think?  any better pathnames for my ideas?  any
better ideas?


.mrg.