Re: procps doesn't buildd - /lib versus /lib64
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/
Reply to: