[RFC PATCH] GCC multilib vs. OS multilib naming

[Daniel Jacobowitz]

On Fri, Sep 20, 2002 at 04:44:51PM +0200, Jakub Jelinek wrote:
> Hi!
> 
> The following patch tries to deal with diferrent GCC and OS multlib schemes.
> Particularly on sparc64/x86_64/ppc64/s390x/irix 64-bit libs are put into
> */lib64 directories, not */lib/64 resp. */lib depending on
> what the configured GCC MULTILIB_DEFAULT is. Similarly 32-bit libs are put
> into */lib directories, not into */lib/32 as GCC does for some
> MULTILIB_DEFAULT settings. On Solaris if GCC MULTILIB_DEFAULT is m32,
> GCC naming scheme matches OS one, but if MULTILIB_DEFAULT is m64,
> OS still uses */lib/sparcv9 for 64-bit and */lib for 32-bit while GCC wants
> to use */lib for 64-bit and */lib/sparcv7 for 32-bit.
> This patch should also fix the --without-multilib Solaris problems,
> as mklibgcc now uses new gcc option to query the information.
> 
> The patch introduces new variable (multilib_os_dir) and new option
> to query it. Unless the OS multilib scheme differs from GCC one, it is the same
> as multilib_dir. On sparc64-linux --with-cpu=v7:
> 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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer