This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Update to current automake/autoconf/libtool versions.
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: klee at apple dot com, gdb-patches at sources dot redhat dot com
- Cc: binutils at sources dot redhat dot com, newlib at sources dot redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 5 Dec 2002 14:07:28 -0500
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
>1. Please make sure to coordinate with Nathanael Nerode, who is in the
>middle of extensive autoconf-related work in the GCC repository.
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.
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
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.