This is the mail archive of the gcc@gcc.gnu.org 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]

autoconf is the wrong tool to use


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


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