This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Update to current automake/autoconf/libtool versions.
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: klee at apple dot com, gdb-patches at sources dot redhat dot com,binutils at sources dot redhat dot com, newlib at sources dot redhat dot com,gcc at gcc dot gnu dot org
- Date: Thu, 05 Dec 2002 14:31:11 -0500
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
- References: <20021205190728.GA11507@doctormoo>
I really would like to see the tree using autoconf 2.5x as soon as
possible; if this can be done before I autoconfiscate the top level
(which is not autoconfiscated yet) it will save me an awful lot of
trouble, since I can then use autoconf 2.5x for that autoconfiscation.
Just a step back here. Some of the directories listed below belong to
the FSF, but some don't. I don't think anyone can be asking Klee to
update non FSF code. That's why I asked Klee to drop RDA from the
Your patch as is updates
bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
Can you please work up a patch for gcc 3.4 to update
boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc
And a patch for Insight
And one for Dejagnu
And for Newlib & Cygwin
I don't think we can guarentee that, but I think we can live with the
libgloss newlib winsup
And one for
and one for
However, I think that it's OK to update one directory at a time,
provided we specify clearly what's going on, and get it all done before
the next release of anything.
Accordingly, I suggest getting clean patches for small sets of
directories, making sure they work, getting them reviewed, and then
putting them in; and then starting on the next set. Keep sending update
notices to the various lists regarding which directories use the 'new'
tools and which use the 'old'. If you can make scripts which work
correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means
do so *first*, and mark those scripts as "compatibile with both", of
course; but I expect that will only happen for the simplest directories.
If this is acceptable to other people in the various groups of course.
I expect this will generate a certain amount of breakage, but then so
did my changes. In both cases, it needs to be done, we just have to
make sure all the breakage gets fixed.
It was mentioned that autoconf2.5 scripts will have trouble with
building because of the top level passing down --target unconditionally.
Unfortunately I think some other aspects of the configure scripts
require --target to be passed down unconditionally. :-/ Otherwise I'd
just change it.