Re: Update GCC to autoconf 2.69, automake 1.15.1

[Eric Gallager <egall@gwmail.gwu.edu>]

On 10/30/18, Joseph Myers <joseph@codesourcery.com> wrote:
> This patch (diffs to generated files omitted below) updates GCC to use
> autoconf 2.69 and automake 1.15.1.  (That's not the latest automake
> version, but it's the one used by binutils-gdb, with which consistency
> is desirable, and in any case seems a useful incremental update that
> should make a future update to 1.16.1 easier.)

Thanks so much for doing this; I've been looking forward to it!

>
> The changes are generally similar to the binutils-gdb ones, and are
> copied from there where shared files and directories are involved
> (there are some further changes to such shared directories, however,
> which I'd expect to apply to binutils-gdb once this patch is in GCC).
> Largely, obsolete AC_PREREQ calls are removed, while many
> AC_LANG_SOURCE calls are added to avoid warnings from aclocal and
> autoconf.  Multilib support is no longer included in core automake,
> meaning that multilib.am needs copying from automake's contrib
> directory into the GCC source tree.  Autoconf 2.69 has Go support, so
> local copies of that support are removed.  I hope the D support will
> soon be submitted to upstream autoconf so the local copy of that can
> be removed in a future update.

Hopefully upstream autoconf will release 2.70 soon; it's been several
years since a 2.70 release has been requested, but no one with the
proper privileges has had the time to pull one together...

>
> Note that the regeneration did not include regeneration of
> fixincludes/config.h.in (attempting such regeneration resulted in all
> the USED_FOR_TARGET conditionals disappearing; and I don't see
> anything in the fixincludes/ directory that would result in such
> conditionals being generated, unlike in the gcc/ directory).  Also
> note that libvtv/testsuite/other-tests/Makefile.in was not
> regenerated; that directory is not listed as a subdirectory for which
> Makefile.in gets regenerated by calling "automake" in libvtv/, so I'm
> not sure how it's meant to be regenerated.
>
> While I mostly fixed warnings should running aclocal / automake /
> autoconf, there were various such warnings from automake in the
> libgfortran, libgo, libgomp, liboffloadmic, libsanitizer, libphobos
> directories that I did not fix, preferring to leave those to the
> relevant subsystem maintainers.  Specifically, most of those warnings
> were of the following form (example from libgfortran):
>
> Makefile.am:48: warning: source file 'caf/single.c' is in a subdirectory,
> Makefile.am:48: but option 'subdir-objects' is disabled
> automake: warning: possible forward-incompatibility.
> automake: At least a source file is in a subdirectory, but the
> 'subdir-objects'
> automake: automake option hasn't been enabled.  For now, the corresponding
> output
> automake: object file(s) will be placed in the top-level directory.
> However,
> automake: this behaviour will change in future Automake versions: they
> will
> automake: unconditionally cause object files to be placed in the same
> subdirectory
> automake: of the corresponding sources.
> automake: You are advised to start using 'subdir-objects' option throughout
> your
> automake: project, to avoid future incompatibilities.
>
> I think it's best for the relevant maintainers to add subdir-objects
> and do any other associated Makefile.am changes needed.  In some cases
> the paths in the warnings involved ../; I don't know if that adds any
> extra complications to the use of subdir-objects.
>
> I've tested this with native, cross and Canadian cross builds.  The
> risk of any OS-specific issues should I hope be rather lower than if a
> libtool upgrade were included (we *should* do such an upgrade at some
> point, but it's more complicated - it involves identifying all our
> local libtool changes to see if any aren't included in the upstream
> version we update to, and reverting an upstream libtool patch that's
> inappropriate for use in GCC); I think it would be better to get this
> update into GCC so that people can test in different configurations
> and we can fix any issues found, rather than to try to get more and
> more testing done before it goes in.
>
> top level:

...[snip]...

> Index: zlib/Makefile.am
> ===================================================================
> --- zlib/Makefile.am	(revision 265631)
> +++ zlib/Makefile.am	(working copy)
> @@ -1,6 +1,6 @@
>  ## Process this file with automake to create Makefile.in.
>
> -AUTOMAKE_OPTIONS = 1.8 cygnus
> +AUTOMAKE_OPTIONS = foreign

To get the modern equivalent of "cygnus" you need not just the
"foreign" option (which you already have), but also the "no-dist"
option in AUTOMAKE_OPTIONS.

>
>  ACLOCAL_AMFLAGS = -I .. -I ../config
>
> @@ -59,3 +59,5 @@
>  	"PICFLAG=$(PICFLAG)" \
>  	"RANLIB=$(RANLIB)" \
>  	"DESTDIR=$(DESTDIR)"
> +
> +include $(top_srcdir)/../multilib.am
> Index: zlib/configure.ac
> ===================================================================
> --- zlib/configure.ac	(revision 265631)
> +++ zlib/configure.ac	(working copy)
> @@ -1,7 +1,6 @@
>  dnl Process this with autoconf to create configure
>
> -AC_PREREQ(2.64)
> -AC_INIT
> +AC_INIT([zlib], [1.1.4])
>  AC_CONFIG_SRCDIR([zlib.h])
>
>  if test -n "${with_target_subdir}"; then
> @@ -14,7 +13,7 @@
>  mkinstalldirs="`cd $ac_aux_dir && ${PWDCMD-pwd}`/mkinstalldirs"
>  AC_SUBST(mkinstalldirs)
>
> -AM_INIT_AUTOMAKE(zlib, 1.1.4)
> +AM_INIT_AUTOMAKE
>
>  AM_MAINTAINER_MODE
>
>
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>