Re: Multilib and Linux.

[hjl@lucon.org (H.J. Lu)]

> 
> > 
> > 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

/lib and /lib/foo64 were suggested for other 32/64 targets.

Also are you suggesting for any library directory, /foo/bar/lib, we
have /foo/bar/lib for 32bit and /foo/bar/lib64 for 64bit?

> 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.

So are you saying we never seach /usr/lib for 64bit? It was suggested
that /usr/lib was searched as a fallback for 64bit. But it is very
tricky and may lead to problems like:

You have libfoo.so in /foo/bar/lib and /bar/lib64, what do you get
with

# gcc .... -L/foo/bar -L/bar/lib64

Please send me the proposal on the behavior of linker on
/foo/bar/lib and /foo/bar/lib64.

BTW, what is the default ABI, 32bit or 64bit? How do you control
it?

> 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.
> 

That is not my concern for now.


> 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.
> 

This should work.

> 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.
> 

We can leave that to RedHat and Debian.

It looks like more than one Linux targets which have to deal with
32bit/64bit ABIs. We should have a common strategy to deal with
all those issues. Should we create a mailing list for it?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)