Add Android related compilation options and multilib options

Joseph S. Myers joseph@codesourcery.com
Wed Jun 17 00:12:00 GMT 2009


On Tue, 16 Jun 2009, Chris Lattner wrote:

> > powerpc-linux is a good case in point of having too many triplets, with
> > variants such as powerpc64-*-linux*, powerpc-*-linux*spe*,
> > powerpc-*-linux*paired*, powerpc*-*-linux*altivec* that should just be
> > variants on the default options and multilibs for one target triplet.
> 
> Why is "more targets bad"?  Life seems simple if you have one set of libraries
> for each target triple, so you have a "many target triples to one set of
> libraries" mapping.  This implies that the major ABI differences get different
> triples though.

If life seems simple you clearly haven't tried working at and beyond the 
limits of what GCC's multilib configuration supports, with large numbers 
of libraries and complicated mappings from the command line options used 
to which runtime libraries to link with.  There are options where you 
don't have the one set of libraries per multilib either; consider how 
ARM's linker can select objects based on build attributes rather than 
based on options passed to the compiler, or the interest from S/390 people 
in having separate hard-DFP versions of libgcc but not of libc, or the 
STT_GNU_IFUNC approach to optimized functions.  Configuration with large 
numbers of libraries is essentially complicated and you should understand 
the existing systems first before proclaiming (cf. Rob Landley's blog) 
that some massively simpler system can solve all the problems in this 
area; such claims suggest that only a much narrower range of 
configurations has actually been thought about.

When you have multiple triplets for essentially the same configuration, 
every case statement in configuration, and every testcase, that wishes to 
test for the configuration, needs to match all the variants, and 
everything that should be in common between the configurations needs to be 
kept in sync - and in practice those powerpc*-linux* targets have got out 
of sync in the past, and testcases have not been properly conditioned to 
run for the correct targets and only the correct targets, and fixing up 
incorrect testsuite presumptions in this area was a pain.  There isn't 
even a meaningful distinction between powerpc64-linux and powerpc-linux 
given that the former is usually built to default to 32-bit with 
--with-cpu=default32.  If you want a compiler that supports both 64-bit 
and SPE multilibs, having them in different targets is no good.  The 
benefits to maintainability of reducing the proliferation of triplets are 
very clear.

And there is an essentially infinite number of possible configurations 
determined by particular options one might want to enable by default; 
converting sets of options into the syntax of target triplets would lead 
to a lot of very long and obscure triplets; configure options such as 
--with-cpu work a lot better and there's no good reason for "default -m64" 
to be handled differently with its own triplet.  Target triplets are not 
meant to encapsulate everything possible about how you might choose to 
configure GCC; there's a reason there are lots of other configure options 
and options that can be used when running GCC.

It has been very clear in the process of cleaning up support for unused 
and obsolete targets that a proliferation of "canonical" target names 
(names that are distinct after being passed through config.sub) is a bad 
idea.  Noncanonical aliases that imply different configuration choices are 
rather less problematic.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list