On Sat, 28 Jul 2001, matthew green wrote:

: OK, i have two problems with the current way sparc & sparc64 support
: 64 bit binaries.  (a) there's seemingly nowhere for sparc64 libraries
: to be installed on a sparc system to enable compiling 64bit objects.

This should require a cross-compiler or a separate, user-supplied library
path.

We do not officially support building binaries for more than one
MACHINE_ARCH with a given native toolchain, even if it Might Work with some
special -option twiddling.  Now, this can be changed, but you need sane
defaults (see bottom).

: (b) the sparc64 `cc -m32' compiler pulls files out of
: /emul/netbsd32/usr/lib and this seems to be wrong to me.

I agree to an extent, but read on.

: the 64 bit SPARC ELF ABI states quite clearly that shared libraries
: will be searched for in /usr/lib/sparcv9.  so our current sparc64 is
: not exactly compliant with the ELF standard.  (of course, i don't
: think any of our ELF ports have ld.elf_so in the "correct place",
: which is normally /usr/lib/ld.so.1.)

Actually, the ELF dynamic linker isn't specified in some platform
supplements, is in a path other than /usr/lib in others, and is not named
"ld.so.1" in still others.  As said before, we do not have to follow the ABI
document when it comes to pathnames, because we define the pathnames for our
binaries; they should be (and are, correctly, in some processor supplements)
platform-dependent.

: i've heard previous objections from tv that this wasn't right for netbsd
: because "system libraries belong in /usr/lib", or some such.  however,
: this isn't necessarily going against that.  even if you consider that the
: sparv9 directory isn't part of /usr/lib, the 32 bit libraries there are
: system libraries anyway.

The system libraries used by *default* by the compiler on a given
MACHINE_ARCH belong in /usr/lib.  I don't necessarily care where libraries
used by binary emulations/compatibility go, so long as a "cc -o foo foo.c"
will use /usr/lib/libc.so as the C library for a given MACHINE_ARCH.  With
that said, there are two choices here:

1. Put 64-bit libraries in /usr/lib on sparc64, and 32-bit libraries
   elsewhere (maybe /usr/lib/sparcv7?), with the compiler defaulting to the
   given bitsize for the given architecture.

   This option is intended to provide the 32-bit libraries only as a means
   of binary compatibility; static libraries and *.o files do not belong in
   /usr/lib/sparcv7 in this case.  A cross compiler should be used to
   compile objects for the foreign bitsize on both sparc and sparc64.

2. Put 32-bit libraries in /usr/lib, and 64-bit libraries in
   /usr/lib/sparcv9, default compiler to creating 32-bit binaries on both
   sparc and sparc64, and require -m64 to create any 64-bit binary.

   This option also somewhat implies that pkgsrc and the base system tools
   will compile themselves as 32-bit by default on both sparc and sparc64
   unless a specific (site-specific, not by default) option is added.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/