This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Understanding Multilibs ;-)
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- To: Phil Edwards <phil at jaj dot com>
- Cc: Nathanael Nerode <neroden at twcny dot rr dot com>, GCC List <gcc at gcc dot gnu dot org>
- Date: 28 Jul 2003 08:56:50 +0200
- Subject: Re: Understanding Multilibs ;-)
- Organization: FAW Ulm
- References: <20030728035750.GA27103@twcny.rr.com> <20030728042521.GA27054@disaster.jaj.com>
On Mon, 2003-07-28 at 06:25, Phil Edwards wrote:
> On Sun, Jul 27, 2003 at 11:57:50PM -0400, Nathanael Nerode wrote:
> > So, I decided to take a crack at moving multilibbing to the top level.
>
> Give me another day or two to check in the v3 transition first?
>
>
> > At first it looked simple: just call gcc --print-multi-lib.
> > Of course it couldn't be *that* simple. ;-)
> >
> > config-ml.in does various per-target per-'enable'-option pruning of the
> > list before operating. But in the code it puts into Makefiles, 'gcc
> > --print-multi-lib' is just used directly. Hmm?
>
> The only Makefiles touched are the post-pruning ones, so that the code
> using --p-m-l directly is operating on a known-good subset of the original
> computer multilib list. Does that help?
The --p-m-l is only invoked inside of configure script at the root of a
multilib hierarchy. Configure scripts to be called for a
multilib-variant don't call --p-m-l, instead they receive their flags
from the "root-configure" script.
> > Well, in any case, what I want to do is this.
> > * Get the list of lib versions and corresponding options.
> > (`gcc --print-multi-lib` if that's really sufficient).
>
> Maybe the per-target-per-enable pruning could be moved up there as well?
> Automake is about to import config-ml.in for their use, so it'd be nice
> to get all the GCC-isms out.
>
>
> > * Create a target subdir for each one (assuming 'a' and 'b' are the
> > lib variants)...
> > i686-pc-linux/a/libstdc++-v3
> > i686-pc-linux/a/libf2c
> > i686-pc-linux/b/libstdc++-v3
> > i686-pc-linux/b/libf2c
> > etc...
>
> Some questions at random:
>
> What is 'a' in the standard/normal/primary/nothing-special case?
IMHO, Nathanael is missing something:
A multilib hierarchy always is a tree, i.e.
libstdc++-v3
a/libstdc++-v3
b/libstdc++-v3
would be a legal multilib hierarchy, while
a/*
b/*
would not be a legal multilib hierarchy, because it lacks the default
"root node"
> What are the names for combinations? 'ab'?
Multilibs are directory trees: So a/b would be correct.
Ralf