[RFC PATCH] GCC multilib vs. OS multilib naming

[Daniel Jacobowitz]

On Fri, Sep 20, 2002 at 11:43:17AM -0400, Jakub Jelinek wrote:
> On Fri, Sep 20, 2002 at 11:28:24AM -0400, Daniel Jacobowitz wrote:
> > > gcc -print-multi-directory
> > > .
> > > gcc -print-multi-os-directory
> > > ../lib
> > 
> > I like the look of this in general, but I've got two questions.
> > 
> >  - Why ../lib?  All the others are relative to a fixed directory, might
> > as well use just '.'.  But that's really minor.
> 
> If people configure with libdir say /usr/lib64 (I saw it several times when
> somebody did something like this), that will loose.
> Especially for libtool or whatever will use -print-multi-os-directory
> it is IMHO better to be clear (and more consistent with ../lib64).
> I'd also have to double check the mklibgcc.in changes if they work
> with it.
> 
> What could be done to avoid all the /usr/lib/gcc-lib/foo/bar/../../..
> (already present before this
> patch) and /usr/lib/gcc-lib/foo/bar/../../../../lib64 or /lib/../lib64
> ugliness could be on Unix hosts a cheap canonicalizer (ie. for
> say /usr/lib/gcc-lib/foo/bar/../../../../lib64 stat that and /usr/lib64
> and if they have the same st_dev and st_ino, use the latter, otherwise
> former). A full-blown realpath(3) is IMHO not needed.

OK, that makes sense.  Thanks.

> >  - Why do we need both?  Couldn't we change GCC's layout to match the
> > OS's regardless of GCC's configuration, so that the OS could override
> > the mapping?  There's probably a reason, but I don't see it.
> 
> Using ../lib64 multilib dir for say /usr/lib/gcc-lib/sparc64-linux/3.2.1/
> directory is not a good idea (it would be shared between say 3.2.1 and
> 3.3).
> If the OS=GCC multilib dirs were lib, lib64 and lib64/alt in sparc64-linux
> case no matter what MULTILIB_DEFAULT is, then all the */lib or libdir
> prefixes would have to suddenly loose the trailing path component
> and even the build directory layout would change a lot, requiring big
> Makefile and config-ml.in surgery.

I think this could be done more easily.  We could leave the directories
the way they are (with ../) and use 3.2.1/lib/ as the tool libdir. 
This would still require separating out what looks for tools vs.
libraries in tooldir, but it should be much simpler... I don't really
like the idea of carrying around two different layouts if we don't have
a technical need to.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer