Updating Autoconf and Automake versions used in GCC and src

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

Hello GCC, binutils, gdb developers,

short summary: I'd like to, in roughly that order,

1) update GCC and src to Autoconf 2.64, Automake 1.11,
2) enable automake dependency tracking for the bfd, binutils, ld,
   opcodes, gprof, and gas directories,
3) bring some more build sanity for libstdc++-v3, including dependency
   tracking,
and maybe
4) update Libtool in GCC and src at some convenient point later.

I'd be grateful about feedback as to whether the general plan is
acceptable for everyone; thanks.


Automake 1.11 has been released a month ago, so far there has been only
one regression reported over previous releases and it is trivial to work
around.  This release provides more efficient "make install", and fixes
some long-standing issues in the libstdc++-v3 build system, and some
other things.  It requires Autoconf 2.62 or newer.

The latest stable Autoconf is 2.63 currently, with 2.64 hopefully
released soon.  2.64 brings shell functions to configure scripts which
can shrink the size of some of the scripts considerably, and some other
fixes; I have so far been testing with the current git tree.

Instead of updating to 2.64, we can also update to 2.63 only, if you
prefer.  It would require working around a number of known bugs that
have since been fixed in Autoconf, and it would not bring the shell
function improvements.  Of course, the switch to 2.64 should anyway be
done only a little while after it has been released, but still well
before the end of GCC Stage 1.  It should be noted that working around
Autoconf bugs should be relatively straightforward (see existing
instances in config/override.m4 and other files).

I understand that most distributions do not ship these versions by
default.  However, that is little different with the 2.59/1.9.6 versions
used by the current trees, so it should not matter much, and improve in
the near future.

(1) will require a flag day, at which developers will need to switch
the Autoconf and Automake they use for the tree if they modify any of
the autotools input files.

I have a number of patches for GCC and src, grown in the last few months
(tracking the infreadead gcc and binutils-gdb git repos of the trees).
I have done some testing, including parallel builds,
'--enable-targets=all --enable-64bit-bfd', but not much
cross-compilation and not on very many different systems.

I'd prefer to do the transition on the GCC trunk rather than in a
branch, unless there is opposition to this.  Keeping a branch in sync
with the src tree seems awkward.  BTW, should I keep any other trees in
sync with these two (archer, out-of-tree libffi)?  Also, I am not aware
of any branches to be merged in GCC which interact non-trivially with an
autotools update.

The transition will consist of a few preparatory patches which keep
using the currently used autotools, and only make the files fit for the
new tools, which I'll start off with.  The final couple of patches for
(1) then flip the Autoconf version bit in config/override.m4, add a few
trivial non-backward-compatible changes, and regenerate everything with
new tools.


There are a few incompatible changes that need addressing:

* changed per-target link flags handling in Automake:

  - Per-target flags are now correctly handled in link rules.

    For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
    for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
    preferred AM_CFLAGS over maude_CFLAGS while linking, and they
    used both AM_LDFLAGS and maude_LDFLAGS on the same link command.

    The fix for compiler flags (i.e., using maude_CFLAGS instead of
    AM_CFLAGS) should not hurt any package since that is how _CFLAGS
    is expected to work (and actually works during compilation).

    However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
    "in addition to" breaks backward compatibility with older versions.
    If your package used both variables, as in

      AM_LDFLAGS = common flags
      bin_PROGRAMS = a b c
      a_LDFLAGS = more flags
      ...

    and assumed *_LDFLAGS would sum up, you should rewrite it as

      AM_LDFLAGS = common flags
      bin_PROGRAMS = a b c
      a_LDFLAGS = $(AM_LDFLAGS) more flags
      ...

    This new behavior of *_LDFLAGS is more coherent with other
    per-target variables, and the way *_LDFLAGS variables were
    considered internally.


* changed installation directory structure and names in Autoconf:

  - datarootdir

  - infodir, docdir, pdfdir, and other point to below ${datarootdir}
    and some have changed defaults (e.g., /usr/local/share/info instead
    if /usr/local/info through this change)


* both tools use awk now in configure and makefiles, but old awks with
  V7 feature set from 1978 should suffice.


More changes are listed in the NEWS files of Autoconf and Automake:
<http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS>
<http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS>


I have gone through the trees and tried to fix all instances where these
changes matter.  The changed per-link flags only occurred in the GCC
tree, the installation directory structure affects all trees, including
documentation.

These messages list some requirements for the autotools update:
<http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00842.html>
<http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01430.html>
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00912.html>
I'm also aware that autoconf/automake tarballs need to be updated
at <ftp://sourceware.org/pub/binutils/>.

I haven't tried the --with-build-sysroot build; can somebody point out
to me what I need to do for an effective test of this?  I'm pretty sure
that updating Autoconf and Automake only will not impact this feature,
though, but I'll confirm before the switch.

I do not intend to update Libtool at the same time: it can safely be
updated independently, and as such I would like to keep the addition of
bugs separate.  ;-)

Of course I volunteer to fix any bugs that stem from this change, please
feel free to Cc: me on any such bug reports.  Since I'm doing this in my
free time, there is necessarily some delay involved in things however.

Thanks for reading this far,
Ralf