Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Michael Poole <mdpoole@troilus.org>]

Bart Trojanowski writes:

>> The decision to put libraries inot /lib and /lib64 has been made quite
>> some time ago and works fine. I would say thats pretty much
>> unchangeable now without a realy good reason. Everyone objecting to
>> /lib64 is a few years to late.
>
> I've actually heard a good solution to the objections...
>
> - install 32bit in /lib/lib*.so,
> - install 64bit in /lib/64/lib*.so,
> - and create a symlink /lib64 -> /lib/64/ for compatibility reasons.

Please do!  If concurrently supported ABIs grow more numerous, this is
the only sane way to grow.  Where I went to university, /usr/local was
a symlink tree that pointed into the local AFS cell.  The customary
setup for each program was similar; a tree like:
  /afs/andrew.cmu.edu/${arch}/gamma/${package}/{bin,lib,etc}
where ${arch} might be sun4, hpux, linux-libc5, and so forth.

The AFS filesystem code made support for this much easier by expanding
the keyword "@sys" in file lookup requests, so I could have a symlink
in my home directory:
  ~/bin/someprogram -> @sys/someprogram
The kernel would know how to resolve that, and I could install the
executables in the appropriate subdirectories of ~/bin.  Since my home
directory was the same no matter which system type I was logged into,
this was a very useful feature.
(I have forgetten some of the details; AFS experts, please excuse me.)

I'm not proposing that there should be a similar @abi expansion done
in the future, but with per-ABI subdirectories (rather than per-ABI
top level directories), multilib becomes much easier to understand.
See also how current glibc on x86 has /lib/tls/i686/cmov.

Michael