Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, 31 Oct 2018 at 04:26, Joseph Myers 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, sorry it took a while for me to get round to looking.
>
> 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 did encounter a problem with ../zlib in libphobos (it built all zlib
objects in-tree). Re-adding target-zlib and using libz_convenience.la
is what I probably should be doing though. Attaching a draft patch
for that.
--
Iain
---
diff --git a/configure.ac b/configure.ac
index b841c9945f0..01048e29c35 100644
--- a/configure.ac
+++ b/configure.ac
@@ -163,7 +163,8 @@ target_libraries="target-libgcc \
target-libobjc \
target-libada \
target-libgo \
- target-libphobos"
+ target-libphobos \
+ target-zlib"
# these tools are built using the target libraries, and are intended to
# run only in the target environment
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index 67eab27e821..ddf30d56aec 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -42,11 +42,12 @@ AC_SUBST(target_alias)
# no-dependencies: Don't generate automatic dependencies.
#(because it breaks when using bootstrap-lean, since some of the
#headers are gone at "make install" time).
+# subdir-objects: Build objects in sub-directories.
# -Wall: Issue all automake warnings.
# -Wno-portability: Don't warn about constructs supported by GNU make.
#(because GCC requires GNU make anyhow).
# -Wno-override: Overrides used in testsuite.
-AM_INIT_AUTOMAKE([1.11.1 foreign no-dist no-define no-dependencies -Wall -Wno-portability -Wno-override])
+AM_INIT_AUTOMAKE([1.11.1 foreign no-dist no-define no-dependencies subdir-objects -Wall -Wno-portability -Wno-override])
m4_rename([_AC_ARG_VAR_PRECIOUS],[glibd_PRECIOUS])
m4_define([_AC_ARG_VAR_PRECIOUS],[])
diff --git a/libphobos/m4/druntime/libraries.m4 b/libphobos/m4/druntime/libraries.m4
index 17f93468b87..7fa36295cb8 100644
--- a/libphobos/m4/druntime/libraries.m4
+++ b/libphobos/m4/druntime/libraries.m4
@@ -45,28 +45,61 @@ AC_DEFUN([DRUNTIME_LIBRARIES_DLOPEN],
# DRUNTIME_LIBRARIES_ZLIB
# ---
# Allow specifying whether to use the system zlib or
-# compiling the zlib included in GCC. Define
-# DRUNTIME_ZLIB_SYSTEM conditional and add zlib to
-# LIBS if necessary.
+# compiling the zlib included in GCC. Adds substitute
+# for LIBZ or adds zlib to LIBS if necessary.
AC_DEFUN([DRUNTIME_LIBRARIES_ZLIB],
[
- AC_ARG_WITH(target-system-zlib,
-AS_HELP_STRING([--with-target-system-zlib],
- [use installed libz (default: no)]))
-
- system_zlib=false
- AS_IF([test "x$with_target_system_zlib" = "xyes"], [
-AC_CHECK_LIB([z], [deflate], [
- system_zlib=yes
-], [
- AC_MSG_ERROR([System zlib not found])
-])
- ], [
-AC_MSG_CHECKING([for zlib])
-AC_MSG_RESULT([just compiled])
- ])
+ AC_LANG_PUSH([C])
+ LIBZ=""
+
+ AC_ARG_WITH(system-zlib,
+AS_HELP_STRING([--with-system-zlib],
+ [use installed libz (default: no)]),
+ [system_zlib=yes],[system_zlib=no])
+
+ AC_MSG_CHECKING([for system zlib])
+ save_LIBS=$LIBS
+ LIBS="$LIBS -lz"
+ dnl the link test is not good enough for ARM32 multilib detection,
+ dnl first check to link, then to run
+ AC_LINK_IFELSE(
+[AC_LANG_PROGRAM([#include ],[gzopen("none", "rb")])],
+[
+ AC_RUN_IFELSE([AC_LANG_SOURCE([[
+#include
+int main() {
+ gzFile file = gzopen("none", "rb");
+ return 0;
+}
+]])],
+[system_zlib_found=yes],
+[system_zlib_found=no],
+dnl no system zlib for cross builds ...
+[system_zlib_found=no]
+ )
+],
+[system_zlib_found=no])
+ LIBS=$save_LIBS
+
+ if test x$system_zlib = xyes; then
+if test x$system_zlib_found = xyes; then
+ AC_MSG_RESULT([found])
+else
+ AC_MSG_RESULT([not found, disabled])
+ system_zlib=no
+fi
+ else
+AC_MSG_RESULT([not enabled])
+ fi
- AM_CONDITIONAL([DRUNTIME_ZLIB_SYSTEM], [test "$with_target_system_zlib" = yes])
+ if test x$system_zlib = xyes; then
+LIBS="$LIBS -lz"
+ else
+LIBZ=../../zlib/libz_convenience.la
+ fi
+
+ AC_SUBST(LIBZ)
+ AC_LANG_POP([C])
])
# DRUNTIME_LIBRARIES_ATOMIC
diff --git a/libphobos/src/Makefile.am b/libphobos/src/Makefile.am
index 3ced3ae21c8..5a9ffbf4306 100644
--- a/libphobos/src/Makefile.am
+++ b/libphobos/src/Makefile.am
@@ -22,9 +22,6 @@ include $(top_srcdir)/d_rules.am
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, Oct 31, 2018 at 7:05 PM Joseph Myers wrote: > I've committed this revised patch version Thank you for taking on this work. > As noted, my expectation is that libgfortran, libgo, libgomp, > liboffloadmic, libsanitizer, libphobos maintainers will deal with > moving those directories to subdir-objects, with any consequent fixes > needed, to eliminate the automake warnings about subdirectory sources > without using subdir-objects - and I don't know whether use of ../ in > source paths in some directories complicates things (if subdir-objects > would result in attempts to put resulting objects in ../, outside the > normal build directory for the library) or not. > Turned out that for libgfortran, at least, this doesn't seem trivial. Problem is that we have some of the sources listed relative to $(srcdir) in Makefile.am, which breaks when enabling subdir-objects. But we can't remove the $(srcdir) either, becase these sources in question are generated from m4 sources when --enable-maintainer-mode is enabled, and $(srcdir) is thus needed so that the generated files will correctly end up in in the source tree and not the build tree. Gah! I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87856 to keep track of this. -- Janne Blomqvist
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, Oct 31, 2018 at 10:04 AM, Joseph Myers wrote:
> On Wed, 31 Oct 2018, Thomas Koenig wrote:
>
>> Am 31.10.18 um 04:26 schrieb Joseph Myers:
>> > This patch (diffs to generated files omitted below) updates GCC to use
>> > autoconf 2.69 and automake 1.15.1.
>>
>> I think this should fix PR 82856. Maybe you could confirm that this
>> restores automake functionality with perl 5.6.26, and mention the PR
>> in the ChangeLog.
>
> At least, the warnings I saw with an older perl version and automake
> 1.11.x are gone when using 1.15.1.
>
> I've committed this revised patch version, minus the libgo changes
> (note the libgo changes in this version have differences from the
> libgo changes in the previous version).
Thanks. I committed the libgo changes, with additional subdir-objects
support (which was trivial), as follows.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 265700)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-8dae05f57f3c8249319e3360b10f07dcc2cd57a7
+df841cce9fd271a25269e3514c2e9b61deaf2c4c
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am (revision 265700)
+++ libgo/Makefile.am (working copy)
@@ -1224,3 +1224,5 @@ clean-local:
distclean-local:
find . -name '*.lo.dep' -print | xargs rm -f
+
+include $(top_srcdir)/../multilib.am
Index: libgo/config/go.m4
===
--- libgo/config/go.m4 (revision 265700)
+++ libgo/config/go.m4 (nonexistent)
@@ -1,92 +0,0 @@
-dnl acinclude.m4 -- configure macros
-
-dnl Copyright 2009 The Go Authors. All rights reserved.
-dnl Use of this source code is governed by a BSD-style
-dnl license that can be found in the LICENSE file.
-
-dnl Go support--this could be in autoconf.
-dnl This version is probably autoconf 2.64 specific.
-
-AC_LANG_DEFINE([Go], [go], [GO], [],
-[ac_ext=go
-ac_compile='$GOC -c $GOCFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD'
-ac_link='$GOC -o conftest$ac_exeext $GOCFLAGS $LDFLAGS conftest.$ac_ext $LIBS
>_MESSAGE_LOG_FD'
-ac_compile_gnu=yes
-])
-
-AU_DEFUN([AC_LANG_GO], [AC_LANG(Go)])
-
-m4_define([AC_LANG_PROGRAM(Go)],
-[package main
-$1
-func main() {
-$2
-}])
-
-m4_define([AC_LANG_IO_PROGRAM(Go)],
-[AC_LANG_PROGRAM([import "os"],
-[if f, err := os.Open("conftest.out", os.O_WRONLY), err != nil {
- os.Exit(1);
- }
- if err := f.Close(); err != nil {
- os.Exit(1);
- }
- os.Exit(0);
-])])
-
-m4_define([AC_LANG_CALL(Go)],
-[AC_LANG_PROGRAM([$1
-m4_if([$2], [main], ,
-[func $2();])],[$2();])])
-
-m4_define([AC_LANG_FUNC_LINK_TRY(Go)],
-[AC_LANG_PROGRAM(
-[func $1() int;
-var f := $1;
-], [return f();])])
-
-m4_define([AC_LANG_BOOL_COMPILE_TRY(Go)],
-[AC_LANG_PROGRAM([$1], [var test_array @<:@1 - 2 * !($2)@:>@;
-test_array @<:@0@:>@ = 0
-])])
-
-m4_define([AC_LANG_INT_SAVE(Go)],
-[AC_LANG_PROGRAM([$1
-import os
-func longval() long { return $2 }
-func ulongval() ulong { return $2 }],
-[panic("unimplemented")])])
-
-AC_DEFUN([AC_LANG_COMPILER(Go)],
-[AC_REQUIRE([AC_PROG_GO])])
-
-AN_MAKEVAR([GOC], [AC_PROG_GO])
-AN_PROGRAM([gccgo], [AC_PROG_GO])
-AC_DEFUN([AC_PROG_GO],
-[AC_LANG_PUSH(Go)dnl
-AC_ARG_VAR([GOC], [Go compiler command])dnl
-AC_ARG_VAR([GOCFLAGS], [Go compiler flags])dnl
-_AC_ARG_VAR_LDFLAGS()dnl
-m4_ifval([$1],
- [AC_CHECK_TOOLS(GOC, [$1])],
-[AC_CHECK_TOOL(GOC, gccgo)
-if test -z "$GOC"; then
- if test -n "$ac_tool_prefix"; then
-AC_CHECK_PROG(GOC, [${ac_tool_prefix}gccgo], [$ac_tool_prefix}gccgo])
- fi
-fi
-if test -z "$GOC"; then
- AC_CHECK_PROG(GOC, gccgo, gccgo, , , gccgo)
-fi
-])
-
-# Provide some information about the compiler.
-_AS_ECHO_LOG([checking for _AC_LANG compiler version])
-set X $ac_compile
-ac_compiler=$[2]
-_AC_DO_LIMIT([$ac_compiler --version >_MESSAGE_LOG_FD])
-m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
-m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
-GOCFLAGS="-g -O2"
-AC_LANG_POP(Go)dnl
-])# AC_PROG_GO
Index: libgo/config/libtool.m4
===
--- libgo/config/libtool.m4 (revision 265700)
+++ libgo/config/libtool.m4 (working copy)
@@ -1084,7 +1084,7 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
# to the aix ld manual.
m4_defun([_LT_SYS_MODULE_PATH_AIX],
[m4_require([_LT_DECL_SED])dnl
-AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+AC_LINK_IFELSE([AC_LANG_SOURCE([AC_LANG_PROGRAM])],[
lt_aix_libpath_sed='
/Import File Strings/,/^$/ {
/^0/ {
@@ -4937,7 +4937,7 @@ _LT_EOF
# implicitly export all symbols.
save_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo
${wl}-update_registry ${wl}/dev/null"
-AC_LINK_IFELSE(int foo(void) {},
+AC_LINK_IFELSE([AC_LANG_SOURCE([int foo(void) {}])],
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, 31 Oct 2018, Eric Gallager wrote: > > 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. As this is code shared with binutils-gdb, I was copying the change made there. (Plus the include of $(top_srcdir)/../multilib.am because zlib can be built as a target module in GCC.) -- Joseph S. Myers jos...@codesourcery.com
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, 31 Oct 2018, Simon Marchi wrote: > On 2018-10-30 11:26 p.m., Joseph Myers 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.) > > Whenever you feel like bumping gcc to 1.16.1, I can take care of binutils-gdb. Before possibly doing that we should get shared files back in sync again. I've just applied my changes to shared files (where they went beyond yours) to binutils-gdb, and also merged a couple of other config/ changes from GCC to binutils-gdb (and done the consequent configure regenerations in libdecnumber and zlib). There are also libiberty changes, and changes to shared various top-level files, that need to be got back in sync. I haven't examined them in detail but it seems mostly to be changes on the GCC side needing to be applied to binutils-gdb. -- Joseph S. Myers jos...@codesourcery.com
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, 31 Oct 2018, Thomas Koenig wrote: > Am 31.10.18 um 04:26 schrieb Joseph Myers: > > This patch (diffs to generated files omitted below) updates GCC to use > > autoconf 2.69 and automake 1.15.1. > > I think this should fix PR 82856. Maybe you could confirm that this > restores automake functionality with perl 5.6.26, and mention the PR > in the ChangeLog. At least, the warnings I saw with an older perl version and automake 1.11.x are gone when using 1.15.1. I've committed this revised patch version, minus the libgo changes (note the libgo changes in this version have differences from the libgo changes in the previous version). A reference to PR bootstrap/82856 has been added. gcc/doc/install.texi has been updated to mention the new versions required. Five lib*/testsuite/Makefile.am files have been updated so they no longer put quotes around their RUNTEST definitions (old automake stored the RUNTEST definition in a shell variable in the makefile, new automake uses '$(SHELL) -c "$(RUNTEST) --version"' which goes wrong when RUNTEST is double-quoted and ends with a space before the closing double quote; I saw this cause problems in libphobos testing, but in principle it's an issue for any of the double-quoted definitions). libphobos and libgo have -Wno-override added to their AM_INIT_AUTOMAKE calls to avoid warnings about their testsuite/Makefile.am files overriding RUNTEST and EXPECT (various other subdirectories already used -Wno-override for that). As noted, my expectation is that libgfortran, libgo, libgomp, liboffloadmic, libsanitizer, libphobos maintainers will deal with moving those directories to subdir-objects, with any consequent fixes needed, to eliminate the automake warnings about subdirectory sources without using subdir-objects - and I don't know whether use of ../ in source paths in some directories complicates things (if subdir-objects would result in attempts to put resulting objects in ../, outside the normal build directory for the library) or not. Update GCC to autoconf 2.69, automake 1.15.1 (PR bootstrap/82856). 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.) 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. Changes to how automake generates runtest calls mean quotes are removed from RUNTEST definitions in five lib*/testsuite/Makefile.am files (libatomic, libgomp, libitm, libphobos, libvtv; some others have RUNTEST definitions without quotes, which are still OK); libgo and libphobos also get -Wno-override added to AM_INIT_AUTOMAKE so those overrides of RUNTEST do not generate automake warnings. 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
Re: Update GCC to autoconf 2.69, automake 1.15.1
On 10/30/18, Joseph Myers 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
Re: Update GCC to autoconf 2.69, automake 1.15.1
On 2018-10-30 11:26 p.m., Joseph Myers 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.) Whenever you feel like bumping gcc to 1.16.1, I can take care of binutils-gdb. Simon
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Tue, Oct 30, 2018 at 8:26 PM, Joseph Myers 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 for doing this. As usual, please skip the patch to the libgo directory; I'll commit that myself. The patch to gotools is fine to commit any time you are ready. Ian
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, Oct 31, 2018 at 4:26 AM Joseph Myers 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.) > > 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. > > 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. OK. Thanks for the work! Richard. > top level: > 2018-10-31 Joseph Myers > > * multilib.am: New file. From automake. > > Merge from binutils-gdb: > 2018-06-19 Simon Marchi > > * libtool.m4: Use AC_LANG_SOURCE. > * configure.ac: Remove AC_PREREQ, use AC_LANG_SOURCE. > * ar-lib: New file. > * test-driver: New file. > * configure: Re-generate. > > config: > 2018-10-31 Joseph Myers > > * math.m4, tls.m4: Use AC_LANG_SOURCE. > > Merge from binutils-gdb: > 2018-06-19 Simon Marchi > > * override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 2.69. > > fixincludes: > 2018-10-31 Joseph Myers > > * configure.ac: Remove AC_PREREQ. > * aclocal.m4, configure: Regenerate. > > gcc: > 2018-10-31 Joseph Myers > > * configure.ac: Remove AC_PREREQ. Use AC_LANG_SOURCE. Use single > line for second argument of AC_DEFINE_UNQUOTED. > * aclocal.m4, config.in, configure: Regenerate. > > gnattools: > 2018-10-31 Joseph Myers > >
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, Oct 31, 2018 at 8:12 AM Thomas Koenig wrote: > > Am 31.10.18 um 04:26 schrieb Joseph Myers: > > This patch (diffs to generated files omitted below) updates GCC to use > > autoconf 2.69 and automake 1.15.1. > > I think this should fix PR 82856. Maybe you could confirm that this > restores automake functionality with perl 5.6.26, and mention the PR > in the ChangeLog. > > > > > 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'm not an automake expert, but I hope to be able to figure out > what is needed. If not, I guess I'll just ask :-) > > What is the plan for the previous branches? Currently, it is necessary > to keep around a special version of automake etc for > --enable-maintainer-mode to work. Backporting a patch which > involves regeneration of files in libgfortran/generated from > the files in libgfortan/m4 would then require keeping two versions > of the relevant tools around, and switching between them. Does the regeneration really involve the automake/autoconf part or would it be feasible to decouple it from --enable-maintainer-mode? > Would it make sense to backport because of this? I don't think so. Richard. > Thanks for your efforts! > > Regards > > Thomas
Re: Update GCC to autoconf 2.69, automake 1.15.1
On Wed, Oct 31, 2018 at 9:12 AM Thomas Koenig wrote: > > 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'm not an automake expert, but I hope to be able to figure out > what is needed. If not, I guess I'll just ask :-) > My understanding is that we need to add 'subdir-objects' to AM_INIT_AUTOMAKE in configure.ac. See e.g. https://autotools.io/automake/options.html (that site is pretty good for describing 'best practices' for modern autotools; there's unfortunately a lot of very outdated autotools tutorials around) What is the plan for the previous branches? Currently, it is necessary > to keep around a special version of automake etc for > --enable-maintainer-mode to work. Backporting a patch which > involves regeneration of files in libgfortran/generated from > the files in libgfortan/m4 would then require keeping two versions > of the relevant tools around, and switching between them. > > Would it make sense to backport because of this? > +1 -- Janne Blomqvist
Re: Update GCC to autoconf 2.69, automake 1.15.1
Am 31.10.18 um 04:26 schrieb Joseph Myers: This patch (diffs to generated files omitted below) updates GCC to use autoconf 2.69 and automake 1.15.1. I think this should fix PR 82856. Maybe you could confirm that this restores automake functionality with perl 5.6.26, and mention the PR in the ChangeLog. 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'm not an automake expert, but I hope to be able to figure out what is needed. If not, I guess I'll just ask :-) What is the plan for the previous branches? Currently, it is necessary to keep around a special version of automake etc for --enable-maintainer-mode to work. Backporting a patch which involves regeneration of files in libgfortran/generated from the files in libgfortan/m4 would then require keeping two versions of the relevant tools around, and switching between them. Would it make sense to backport because of this? Thanks for your efforts! Regards Thomas
