Subject: Re: ELF ABI support for sparcV9 binaries.
To: Eduardo Horvath <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 07/10/2000 12:03:10
On Mon, 10 Jul 2000, Eduardo Horvath wrote:
: Apparently we need to add the following routines to the dynamic linker:
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
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"
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 (firstname.lastname@example.org)