On Mon, 10 Jul 2000, Todd Vierling wrote:

> 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.

This is in the section about shared libraries and `libsys'.  I don't think
static libraries require them.  I have not yet had any instances of
linkage issues where static binaries required them.

> 
> : 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?)

[I probably should trim that but i can't figure out what to cut.]

gcc for sparc has a MULTI_MODE option where a single cc front end driver
can generate both 32-bit and 64-bit binaries based on a single command
line option.

If you go with what you propose, having 32-bit libraries in
/emul/netbsd32/usr/lib and 64-bit libraries in /usr/lib or
/usr/lib/sparcV9, will we be able to configure the gcc driver to be able
to generate both types of binaries?  Without having to specify
-L/emul/netbsd32/usr/lib on the command line?

Eduardo Horvath