On Tue, Mar 02, 2004 at 12:45:41AM -0500, Albert Cahalan wrote: > On Mon, 2004-03-01 at 23:38, Ben Collins wrote: > > > Yes, we could do something lame like /usr/sparc64-linux/lib, > > but then we can't get the same affect of /lib64 for systems > > where /usr is not on the root partition, and it excludes > > using 64-bit for some situations. Not only that, but usually > > /usr/<target_host>/* is reserved for cross-compilation setups, > > which this is not. It's a native runtime. > > If it looks like a duck and quacks like a duck... > If I set up an i386 box with a SCO Xenix ABI > module and gcc set to produce Xenix binaries > by default, that still doesn't make it native. > > Does it???? > > There's nothing lame about /usr/sparc64-linux/lib if > you use it to run 64-bit apps on an essentially 32-bit > kernel. (an ILP32 kernel that saves wide registers but > refuses to create memory mappings above 4 GB) In this > case, putting 32-bit libraries in /lib would be fine.
That's the thing, it's not a 32-bit kernel. sparc64 runs a 64-bit kernel. The debian-sparc port runs on sparc and sparc64. We want 32-bit userspace default for sparc64, even though it runs a 64-bit kernel, but we also want the option to have 64-bit userland overlay that userspace, and we want it in a way that it runs essentially the same way as you would 32-bit apps, natively. That's the whole point. We aren't going to make a debian-sparc64 port, with fully native 64-bit apps for sparc64 machines, so the overlay is the only way, and doing it with /lib64:/usr/lib64 is the only way to get the functionality working as passively as possible. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/