autoconf is the wrong tool to use

autoconf is the wrong tool to use

[Kean Johnston]

All,

This is mostly a followup to my previous request to check
some changes in to not use -shared when trying to drive ld,
and is also related to a conversation I had with Richard
Henderson about the detection of whether or not .init_array
and friends are available. I think that conversation needs
a wider audience because the more I look at this, the more
I am convinced that autoconf is the wrong tool to be using
in GCC. Its fine for detecting host features we need to
do a bootstrap but it is (IMHO) totally inappropriate for
detecting any target parameters whatsoever.

Currently, aclocal.m4 has quite a lot of code that tries
to discern assembler and link editor features. By virtue of
the fact that people may be cross-compiling, that code
goes to some length to see if that's the case for *this*
invocation, and tries to make intuitive guesses about the
target. But the problem is, they are just that. Guesses.
They also assume a full Cygnus like tree where you are
building the entire toolchain (binutils specifically)
alongside the gcc build. That's a bad assumption to make.
There are countless reasons why people would want to do
cross-compiles of just gcc, and the rest of the tools that
autoconf is looking for just don't exist, which leads to
the mis-detection of certain features. On some platforms
you don't even have the option of using the binutils tools
and have to use native ones, which further indicates the
flaw in the design (although in that particular case, if
the binutils arent being used its unlikely you are cross-
compiling, but still).

So, I submit that the current scheme of detecting assembler
and link editor (and even, in some cases, runtime) behaviour
with autoconf sounds like a good idea on paper, but it
really isn't suitable for what GCC is trying to be and do.
Assembler, link editor and runtime features belong in
target macros. If those are painful to maintain (which
they're not really) then some other scheme could be found
to make that maintenance stress easier.

Kean

Re: autoconf is the wrong tool to use

[Richard Henderson]

On Wed, Apr 23, 2003 at 02:58:51PM -0700, Kean Johnston wrote:
> If those are painful to maintain (which they're not really)
> then some other scheme could be found to make that maintenance
> stress easier.

They are *extremely* painful to maintain.  That's how we ended
up with the situation that we have.

It works perfectly well for the native case, which is BY FAR the
most common, and where we see the most variance in system toolchain
features.  For the cross-compile case, we can afford to say thou
shalt use gas, or fend for yourself.


r~

RE: autoconf is the wrong tool to use

[Kean Johnston]

> It works perfectly well for the native case, which is BY FAR the
> most common, and where we see the most variance in system toolchain
Ah ok ... if that is the most common then it is indeed a moot point.

> features.  For the cross-compile case, we can afford to say thou
> shalt use gas, or fend for yourself.
Fair enough :) Objection to autoconf withdrawn.

Kean

Re: autoconf is the wrong tool to use

[Mike Stump]

On Wednesday, April 23, 2003, at 02:58 PM, Kean Johnston wrote:
> I am convinced that autoconf is the wrong tool to be using
> in GCC. Its fine for detecting host features we need to
> do a bootstrap but it is (IMHO) totally inappropriate for
> detecting any target parameters whatsoever.

No.  It is appropriate, you just have to understand the design.  :-)

Think of autoconf as a feature extraction mechanism.  Given M and Q and 
T, it yields A.  M is the running machine (with environment).  Q are 
all the questions we are interested in having answers to, and T is the 
target triplet.  Normally in native build (M is of type T), the answers 
(A) are determined by running code snippets.  However, that is not 
required by the design.  It is perfectly permissible for autoconf to 
consult a web page populated with static answers that are generated by 
hand, by an oracle, or by a previous run of snippets on some other 
machine.  Given Q and T (ignoring M), it can still yield A.

If there are multiple sets of answers per T, then, imagine if T is 
augmented with out of band information that can map to exactly one set 
of answers for A.

You can see how config.cache fits into such a scheme, just a cache of 
answers to previous questions.

So, maybe you want to enhance autoconf to do something more?