This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Update GCC to autoconf 2.69, automake 1.15.1
- From: Eric Gallager <egall at gwmail dot gwu dot edu>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, bkorb at gnu dot org, ibuclaw at gdcproject dot org, ian at airs dot com, jakub at redhat dot com, cmtice at google dot com, simon dot marchi at ericsson dot com
- Date: Wed, 31 Oct 2018 12:38:02 -0400
- Subject: Re: Update GCC to autoconf 2.69, automake 1.15.1
- References: <alpine.DEB.2.21.1810310322420.32487@digraph.polyomino.org.uk>
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
>