This is the mail archive of the
mailing list for the GCC project.
Re: Add Android related compilation options and multilib options
On Wed, 17 Jun 2009, Chris Lattner wrote:
> > 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.
> I'm also not familiar with Rob Landley's blog.
He makes various wide-ranging claims about most of the path searching
logic in GCC being unnecessary. It may not be needed in his environment,
but all the different cases do have their own purpose (even if the results
of adding features for successive use cases seem uglier than a design for
all use cases produced at one go might). Path searching and multilibs are
heavily interwoven, and the same issues apply to both.
> Ah interesting. I certainly wasn't considering how the GCC testsuite works
> and what its requirements are. Basing the testsuite on the *input* triple to
> the compiler seems to have many complexities.
It (DejaGnu) uses the *canonical* triplets as output by config.sub, but
the difficulties arise where config.sub's ideas of what should be
distinguished are at variance with what is actually of use for GCC to
distinguish. And where config.sub distinguishes more than necessary, the
multiple ways to get the same effect (i686-* versus i386-*
--with-cpu=i686) cause trouble and confusion. For a from-scratch design I
would have eliminated many of these variants and replaced them by
appropriate configure options, and the way to have a multi-target compiler
whose targets have the same canonical triplet after such unification (e.g.
Power SPE and 64-bit) would be to build different multilibs for that
target rather than building them as different targets; the multi-target
compiler should not need to use different target structures for them. A
compiler might naturally be configured to support
multilib -m32 -mcpu=8540
and I think having two targets with multiple sets of libraries each is a
better way of describing this than
which would be how you'd do it with one target triplet = one set of
libraries (I've removed the "company" part from the triplets here as
always useless except when misused).
Joseph S. Myers