Re: Update autotools version for gdb and binutils

[Alan Modra <amodra at gmail dot com>]

On Wed, May 09, 2018 at 11:46:26AM -0400, Simon Marchi wrote:
> On 2018-05-08 18:12, Joseph Myers wrote:
> > On Tue, 8 May 2018, Alan Modra wrote:
> > 
> > > I wasn't saying you must change all of binutils-gdb, let alone gcc,
> > > just that it would be nice.  binutils-gdb config/* is copied from gcc
> > 
> > And as it's the start of development for GCC 9, it's essentially the
> > optimal time for such a risky change in GCC.
> > 
> > It's libtool for which an update may be the riskiest (necessary to
> > revert
> > libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see
> > <https://gcc.gnu.org/ml/gcc-patches/2011-01/msg00520.html>, and need to
> > check for any local changes relative to the last libtool version merged
> > from that aren't in the new libtool version used).  I don't know whether
> > updating other tools in GCC would require updating libtool or whether
> > the
> > updates can be independent.
> 
> I attempted to convert binutils-gdb to autoconf 2.69 / automake 1.15.1 and
> it went reasonably well.  I don't know very much about gcc, so I could try
> to do the same in the gcc tree blindly, but I don't feel confident enough to
> test and validate the changes.  So I would avoid it if I can, somebody more
> used to building gcc could do that part.
> 
> Could we first rule whether we still need to support combined tree builds?
> I don't have the necessary background to judge the importance of that
> feature, but it would basically decide whether I can update the tools used
> in binutils-gdb in isolation from gcc.

The only combined tree issue I can think of when _GCC_AUTOCONF_VERSION
differs between gcc and binutils-gdb, is that --enable-maintainer-mode
might attempt to run the "wrong" autoconf on one of the trees.  That
shouldn't be a show-stopper.

Let's see the patches.

-- 
Alan Modra
Australia Development Lab, IBM