This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [toplevel] Gas install name problem from autoconf 2.5x

On Wed, Sep 03, 2003 at 09:13:45AM -0700, Ian Lance Taylor wrote:
> DJ Delorie <> writes:
> > > How do we feel about migrating towards the new autoconf definitions -
> > > i.e. anything with --host is cross-compiled, anything with --target is
> > > a cross-compiler.
> > 
> > That breaks cases where you use --host to override config.guess's idea
> > of the system name, i.e. to provide a canonical triplet across a range
> > of build hosts that are compatible yet guess to different triples.
> The new scheme is to specify --build instead.  $host defaults to
> $build.

Unfortunately I'm not sure that this works with older versions of
autoconf.  In fact I'm pretty sure that it doesn't.

> > It also breaks automated builds which aren't smart enough to even
> > consider the possibility that you won't provide all three.  Er, like
> > one of mine, which is table driven.
> Yes.

Yes.  This will break:
 - the test scripts I've been using for testing autoconf udpates.  Isn't it
 - All of MontaVista's toolchain build scripts.

I can't say that I'm thrilled.

> > We should be liberal in what we accept.  We once discussed
> > auto-detecting which autoconf each subdirectory used, and filtering
> > command lines accordingly.  I suspect this is still a good idea.
> > Don't expect the user to be smart about this, they won't be.
> I think that is what is required until everything is updated.
> It still leaves the top level problem--the behaviour changes at the
> top level, which means that users have to change.

I think that, as you said, we do not have any choice.  The alternative
is forking autoconf to reverse the decision, and I certainly don't
want to do that.

What do folks think about biting the bullet, documenting the new
semantics, and trying to get every affected directory before the next
releases of binutils/gcc/gdb?  I believe that none of the other
projects in src will be affected, they're all target apps or target

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]