Re: PROPOSED: 32/64 bit coexistance

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Sep 17, 2001 at 10:11:51PM +0200, Oliver Paukstadt wrote:
> First we have two loaders both residing in /lib, a 32 bit and a 64 bit
> loader.
> On Linux for zSeries this are /lib/ld.so.1 for 32 bit architectures and
> /lib/ld64.so.1 for the 64 bit architectures.

It does not matter much where dynamic linker resides, what matters where
libraries reside.
The whole point here is that on several architectures there is no clear
division between what "emulation" resp. "compatibility" and what "real"
libraries are. If the 64bit support in the CPU is just a strightforward
extension of 32(1) bit architecture, then you really want to have some
programs 64bit where it is reasonable and other programs 32bit because they
will run faster (because of smaller cache footprint).
This is definitely the case on mips (look at Irix), on SPARC (where I
modeled this for Linux based on the Irix layout, but Solaris uses something
similar, just look at fhs-discuss archives (are there any?) when I brought
this up)), on X86-64 and as far as I understand on PowerPC and S390 too.

> The second problem is about packaging. In my opinion it is a task for the
> package manager to find the right place for the shared libraries. Lets
> talk about RPM, thats the only on I have experiences with.
> All packages would have the /lib and /usr/lib (are we talking about
> /usr/lib as well ?) pathes in it, because the natural architecture (imho)
> should always reside in plain pathes without numbers. Only compatibility
> architectures should reside in /libXX and /usr/libXX

See above. On some 64bit arches (like IA-64) there is clear natural
architecture and compatibility arch, but not on others.

> Then it is a task of the package-manager to detect compatibility
> architectures and relocate the files for /lib to /lib32 and /usr/lib to
> /usr/lib32.

Then you have stuff like apps dlopening their shared libraries by full path
and you loose.

> I don't know if it makes sense to build 128 bit CPUs, but then we would
> have /lib for the native 128 bit architecture, /lib64 for the 64 bit
> compatibility architecture and /lib32 for the 32 bit compatibility
> architecture. With your appraoch you than need /lib pointing to /lib32 and
> /lib64. Don't be to shortsighted.

If the 64bit libraries are put in */lib64 directories and the architecture
is extended to 128 bits, you just put 128 bit libs into */lib128, no big
problem. On arches which are 32/64/... bit, */lib will simply be for 32bit
libs (and files common to all ABIs), I don't think there is actually need
for */lib32 (unless you have 16/32bit arches).

> I don't know if there are RPM or RedHat people on the list, because there
> are no redhat people among the explict named recipients. We should talk to
> the rpm people because I think if the package manager could solve our
> problem, we should solve the problem in a clean way and not have /lib
> pointing to /lib32 or /lib64 depending on an existant compatibility
> architecture or not. Great standard. ;-/

IMHO putting the stuff in */lib and */lib64 is a clean way, I even coded
support for this into rpm (%multilib stuff), though had no time to maintain
that stuff, so in latest rpm versions this code is present, but needs
fixing (about a year ago it worked just fine).
The code in rpm marked libraries with special attributes, and rpm would
allow you to install say foo-1.0-1.sparc.rpm and foo-1.0-1.sparc64.rpm on
the same machine (one package would be the primary, the other would be
installed in "just libs" mode).
If e.g. foo*.sparc.rpm contained:
/bin/foo
/usr/lib/libfoo.so.1

(and foo*.sparc64.rpm
/bin/foo
/usr/lib64/libfoo.so.1
), then installing them both, with 32bit one as primary one would end up
with
/bin/foo (from 32bit package)
/usr/lib/libfoo.so.1
/usr/lib64/libfoo.so.1

That way, you can install both 32bit and 64bit packages which use
libfoo.so.1, but you of course don't need to have two copies of the same
program (similarly with data).

> Another point is that you need a ldconfig and a ldconfig32 or a unified
> ldconfig managaing the compatibility architectures as well. The same is
> with ldd, ld.so.conf and so on. In your suggestion we get an ldconfig and
> an ldconfig64. I think with this analogy it should be clear which
> version gets the numbers and which gets the plain name. A special ldconfig
> for the native architecture is not intuitional.

glibc has a unified ldconfig managing multiple ABIs which supports Sparc
(native 32/64), IA-64 (native/IA-32 compatibility), X86-64 (native 32/64),
S390 (native 31/64). Similarly with ldd (looks like just ldd on Sparc
handles this, will make a patch for other arches), ld.so.conf. This
works just fine in the */lib, */lib64 layout.

> And most distributors say "one source package for all architectures" so
> you need to use macros in your rpm spec file and especially in your %post
> and %pre scripts because on 64 bit architectures /lib is /lib64 and on 32
> bit architectures it is /lib or /lib32.

You don't need to change much, and rpm already provides the macros you need.

	Jakub