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

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Josselin Mouette <josselin.mouette@ens-lyon.org> writes:

> Le dim 11/01/2004 à 08:00, Goswin von Brederlow a écrit :
> > The currently implemented idea was to rename the amd64 package of
> > libfoobar to lib64foobar and have amd64 binary packages depend on that
> > name instead. libfoobar.so goes to /lib and lib64foobar.so to
> > /lib64. That works so far.
> 
> Am I the only one to think the whole /lib64 idea is fundamentally
> broken? We already have ia64 without this. We can build a very similar

ia64 can't run 32 bit code like amd64, it can only emulate it. Afaik
ia64 has 32bit libs in /lib32. How is that any different?

> system for amd64, introducing a new arch. Then, ship a few 32-bit
> compatibility libraries for 32-bit proprietary software.

You would have to recompile every binary or add some obscure hacks to
get /lib32 to work on amd64.

> Or is this choice made just because Redhat already made it? What is good
> for Redhat is not necessarily good for us. We already have 64-bit
> arches, we already deal with them properly, and we need almost no
> changes to our infrastructure to introduce amd64 as a whole new arch.

The /lib64 is the way everyone else on amd64 does it. By now the main
argument for a /lib64 at all is because everyone does it. Doing an
64it only port for amd64 (without /lib64) would certainly be possible
but incompatible to everyone else.

Also there are 4 (not just 3 as in the topic) othger archs that have
exactly the same problem:

sparc64, mips64, s390x, ppc64.

And they certainly don't want a 64bit only port due to code size and
thus speed reasons.

Multiarch support is comming so amd64 can hitch a ride as well. That
also means that the amd64 patches from SuSe and RH can be used along
with 64bit patches from sparc64, mips64, s390x, ppc64.

MfG
        Goswin