On Mon, 10 Jul 2000, Eduardo Horvath wrote:

: Apparently we need to add the following routines to the dynamic linker:
: 	__align_copy1

Dynamic linker?  If these are generated by the compiler, they need to be in
libc--think static binaries.  Remember that all but a very small number of
binaries on Solaris are dynamic (and thus will always have these available),
even those in /sbin and /bin.  So if these are needed for runtime support,
keep our static binaries in mind.

: However, the ABI also appears to specify in section 6.1 that libraries
: need to go into the /usr/lib/sparcV9/ directory.
: 
: How much damage will it do to the toolchain to move 64-bit libraries
: there?  It would certainly help if we didn't require a full 32-bit
: installation in /emul/netbsd32.

The location /usr/lib/sparcV9 is more-or-less arbitrary, and from what I can
tell, chosen by Sun because "Solaris does it" and "SUNWspro uses it".  This
is fine and dandy, but it implies that /usr/lib contains 32-bit
binaries--which, for a 64-bit-only "native" system, would not necessarily be
true.

My personal _opinion_ is that /usr/lib should contain the "native" platform
libraries.  If the default of the sparc64 compiler is 64-bit binaries, then
/usr/lib should contain 64-bit libraries, and you can fetch 32-bit
counterparts from /emul/netbsd32/usr/lib.  Note I didn't say that
/emul/netbsd32 needs a full distribution--just the libraries.

*****

This boils down to _why_ the libraries for the "native" 64-bit system should
be in a directory other than /usr/lib, which for sparc64 is "so that the
compiler can generate both 32-bit or 64-bit executables".  That's an issue
completely orthogonal to the location of the libraries.

I could, in fact, make the now-ELF i386 platform capable of creating Linux,
FreeBSD, and BSD/OS binaries simply by changing the crt0 start files,
library paths, and include path, without changing the toolchain itself--only
compiler and linker options.  Same goes for building little-endian MIPS
binaries on a big-endian system.  However, I don't have Linux libraries in
/usr/lib/linux--they're under an /emul tree, as they are not "native"
libraries.

*****

Compromise proposal:  If we *really* want the 64-bit libraries visible
through /usr/lib/sparcV9, create a symlink that points to `.' at that
location, and keep the 32-bit libraries where they belong--in emulation.  
This way we don't add Linuxlike complication to our clean, _uniform_
cross-platform path structure.

IMHO, the ELF spec should have no authority to determine library locations,
just the binary file formats they use.  (Should we put ld.elf_so instead in
/usr/lib/ld.so.1, just to do the same thing Solaris does?)

-- 
-- Todd Vierling (tv@pobox.com)