Re: [RFC] Update to current automake/autoconf/libtool versions.

[Nathanael Nerode <neroden@twcny.rr.com>]

>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 
libstdc++-v3 zlib

And a patch for Insight
itcl libgui

And one for Dejagnu
dejagnu expect

And for Newlib & Cygwin
libgloss newlib winsup

And one for
sid

and one for
intl

--
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.

--Nathanael

P.S.
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.