configure problems: possibly undefined macro: AS_FOR_TARGET
Tue Jan 7 17:30:00 GMT 2003
> m Mon, 2003-01-06 um 22.17 schrieb Christian JÃ¶nsson:
>> > > Are we on the road to 2.5x?
>> > No.
This is false. Klee Dienes and others have been working overtime for
months doing exactly that. Nathanael Nerode and others have been doing
similar work on the gcc tree. And, since we all live in uberbaum, the
toplevel affects everbody...including newlib and winsup(cygwin).
"[RFC] Update to current automake/autoconf/libtool versions.
"Planning for the Autoconf 2.5x transition?"
>> > This is a problem in your system's wrapper.
Technically, the problem is that the cygwin wrapper defaults to 2.5x,
not 2.13. The Mandrake 9.0 autoconf wrapper is the opposite: it
defaults to 2.13 not 2.5x.
However, before you say "Well, mandrake is right and cygwin is wrong",
cygwin is a relatively new platform (compared to linux or solaris or
hpus), and the support for our system under autoconf-2.13 is, err,
somewhat less than optimal; ditto the other autotools.
On the plus side, current cvs libtool supports cygwin very well, but it
requires automake-1.7.x, which in turn requires autoconf-2.5x -- which
both, in their own way, support cygwin better than obsolete versions do.
So, it's perfectly reasonable that on our platform, the wrappers default
to the versions best suited for our platform. The same argument is not
true for Mandrake; all versions support linux cleanly. Oh -- and one
other thing, we've been using these wrappers for over two years now with
complete success; we saw the problem -- and implemented the solution --
to the autoconf incompatibility long before anyone else did so.
Now, BOTH the Mandrake wrapper and the cygwin wrapper 'key' off of the
AC_PREREQ() argument to correctly pick which version of autoconf to use.
The only difference is which version a given wrapper will choose to
use when there is no AC_PREREQ() command at all. [Why, after all,
choose the minimum version when given no guidance? Why not the choose
the most featureful, least buggy version by default -- since we usually
assume that opensource software gets *better* as time goes on...]
>> well, regardless, it is suggested recently on the cygwin list that
>> binutils or more correct I guess, the top-level configure.in to have
>> this patch in it
> AC_PREREQ specifies the minimum version being required by a
> => AC_PREREQ(2.13) does _not_ specify wanting autoconf-2.13 instead of
True -- but it is ALSO accepted practice (okay, only two data points;
but if you are bigoted against cygwin, surely Mandrake Linux carries
some weight) for wrapper scripts to use AC_PREREQ to help pick the
version to use.
And, if a given configure script is 2.13-compatible only, and does NOT
WORK with 2.5x, that fact SHOULD be indicated somehow, right? But, the
command used to indicate that needs to be supported by both stock 2.13
and stock 2.5x. Our choices are somewhat limited in that regard...
And stating 'AC_PREREQ(2.13)' in the configure.in script has no real
effect on *you*, since you're already using 2.13 -- there isn't anybody
out there using 2.11 or 2.05, is there? Hell, if so, then just say
"AC_PREREQ(2.00)" if you like. Any well-written wrapper, built to
handle the backwards incompatibility between end-of-lifed 2.13 and 2.5x
will compare VER_MIN <= 13, not VER_MIN == 13. (although cygwin's
wrapper assumes and does not test that VER_MAJ == 2).
The pedantic could argue that ALL modern configure.in scripts that
assume ac-2.xx, xx < 50, but do NOT say AC_PREREQ(2.00) are wrong --
because some fool out there might have a copy of autoconf-1.x, right?
Fortunately, I'm not pedantic.
> [AFAIK, there exist some hacked versions of autoconf which try to apply
> AC_PREREQ(2.13) to destinguish if a configure script wants
> autoconf-2.13, but this behavior is beyond the definition of AC_PREREQ,
> ie. is plain wrong.]
No, there are several platforms that use wrapper scripts and
AC_PREREQ(), but they don't hack autoconf itself AFAIK.
> => This patch is useless.
You mean, in your opinion this patch is not worthy of application. It
is certainly NOT useless, since it SOLVES THE PROBLEM.
Now, this is not to say that we (cygwin) wouldn't like to work with the
binutils/gcc/uberbaum people. (winsup i.e. cygwin lives in uberbaum,
too). What about this:
to acinclude.m4, and we'll change our wrappers to look at both
AC_PREREQ() and *_AC_MAXVER(), and do the obvious thing.
[side note: it'd be nice to propose 'AC_MAXVER()' and push that into
autoconf, but we'd need to wait for the next version of each development
line to be released: 2.58 and 2.14...oops. There will be no 2.14. So
we can't do that.]
Or...binutils could allow this harmless overloaded interpretation of
cygwin autoconf co-maintainer
cygwin automake co-maintainer
cygwin libtool maintainer
cygwin autotool wrappers maintainer
More information about the Binutils