On 10/30/18, Joseph Myers <jos...@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
> jos...@codesourcery.com
>
