This is the mail archive of the
mailing list for the GCC project.
Re: [RFC PATCH] GCC multilib vs. OS multilib naming
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 20 Sep 2002 11:28:24 -0400
- Subject: Re: [RFC PATCH] GCC multilib vs. OS multilib naming
- References: <20020920164451.C5743@sunsite.ms.mff.cuni.cz>
On Fri, Sep 20, 2002 at 04:44:51PM +0200, Jakub Jelinek wrote:
> 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
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.
MontaVista Software Debian GNU/Linux Developer