Re: Multilib and Linux.

[Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>]

> 
> Hi, Folks,
> 
> Linux will move to multilib soon. I know egcs supports multilib.
> But I have some doubts how well it will work on Linux. ELF/PPC
> has 2 ABIs. But I don't know any Linux/PPC distribution supports
> both ABIs. I don't think the "nof" ABI is supported. I don't think
> it is trivial to build such a distribution. I don't even know if
> it is necessary for Linux. I'd like to hear what people's views
> on it.

Linux/SPARC needs two ABIs (32bit and 64bit) as well. I've added
multilibing into Linux/Sparc egcs and I think it must work, although
currently we still don't have the 64bit ABI packages as egcs miscompiles
glibc in 64bit ABI.

The scheme I had in mind was:
have /lib, /usr/lib, /usr/X11R6/lib for the 32bit ABI shared & static libraries
/lib64, /usr/lib64, /usr/X11R6/lib64 for the 64bit ABI shared & static libraries
plus those few gcc libraries and objects live in the classical multilib
paths /usr/lib/gcc-lib/egcs*/*/64/ and egcs*/*/
specs files of gcc then add either set of these library paths.
That could work with the current binutils, although one change might be
handy: if linker found a library of the other ABI type in the search path,
it would not barf completely, but continue with searching in the search
path.
I'm now discussing how to handle both types of libraries (and possibly
further types, like libs optimized for some particular CPU) within one
ld.so.cache with Ulrich Drepper.

Another issue is include files, but IMHO that's solvable by ifdefs. We
already have /usr/include/asm/ full of small stubs like
asi.h:
#ifdef __sparc_v9__
#include <asm-sparc64/asi.h>
#else
#include <asm/asi.h>
#endif
In glibc, I guess just a few headers are sparc64/sparc dependant and
different for those, so we can easily hack it together so that it has both
variants in, plus there are a few headers for 32bit and 64bit platforms, so
maybe if wordsize-3264 would be coded and had some define which would tell
it which wordsize to use, things might look good.

And another thing to solve, which does not have to do anything with egcs nor
glibc, is package management, ie. rpm and deb. Either the dist maintainers
will split all packages containing shared/static libraries into subpackages:
one package with the programs, one package with the libraries and allow
installing e.g. both library types (that would be a lot of work, but could
be doable with the current package features), or rpm/deb could handle this
by themselves, ie. be able to install a package twice, the second time only
shared/static libraries stuff.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux  |  http://ultra.linux.cz/  |  http://ultra.penguin.cz/
Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________