[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9edb6725717d668d144b2075f0dabf03ac4ec3d8

commit r14-1488-g9edb6725717d668d144b2075f0dabf03ac4ec3d8
Author: Thomas Schwinge 
Date:   Mon May 15 20:55:11 2023 +0200

Back to requiring "Perl version 5.6.1 (or later)" [PR82856]

With Subversion r265695 (Git commit
22e052725189a472e4e86ebb6595278a49f4bcdd)
"Update GCC to autoconf 2.69, automake 1.15.1 (PR bootstrap/82856)" we're
back
to normal; per Automake 1.15.1 'configure.ac' still "[...] perl 5.6 or
better
is required [...]".

PR bootstrap/82856
gcc/
* doc/install.texi (Perl): Back to requiring "Perl version 5.6.1
(or
later)".

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Thomas Schwinge  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #14 from Thomas Schwinge  ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Thomas Koenig from comment #7)
> > Author: tkoenig
> > Date: Thu Nov 16 20:24:00 2017
> > New Revision: 254845
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=254845=gcc=rev
> > Log:
> > 2017-11-16  Thomas Koenig  
> > 
> > PR bootstrap/82856
> > * doc/install.texi: Document incompatibility of Perl >=5.6.26
> > with the required version of automake 1.11.6.
> > 
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/doc/install.texi
> 
> Thomas, this patch refers to a non-existent 5.6.26 version (did you mean
> 5.26.0?)
> 
> But is this even still relevant now that we've updated the automake version?
> Can we revert it to just say 5.6.1 or later?

Indeed; 
"Back to requiring "Perl version 5.6.1 (or later)" [PR82856]".

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #13 from Jonathan Wakely  ---
(In reply to Thomas Koenig from comment #7)
> Author: tkoenig
> Date: Thu Nov 16 20:24:00 2017
> New Revision: 254845
> 
> URL: https://gcc.gnu.org/viewcvs?rev=254845=gcc=rev
> Log:
> 2017-11-16  Thomas Koenig  
> 
>   PR bootstrap/82856
>   * doc/install.texi: Document incompatibility of Perl >=5.6.26
>   with the required version of automake 1.11.6.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/doc/install.texi

Thomas, this patch refers to a non-existent 5.6.26 version (did you mean
5.26.0?)

But is this even still relevant now that we've updated the automake version?
Can we revert it to just say 5.6.1 or later?

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Oct 31 20:46:17 2018
New Revision: 265701

URL: https://gcc.gnu.org/viewcvs?rev=265701=gcc=rev
Log:
PR bootstrap/82856

libgo: update to autoconf 2.69 and automake 1.15.1

Initial patch from Joseph Myers.

Reviewed-on: https://go-review.googlesource.com/c/146417

Removed:
trunk/libgo/config/go.m4
Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in
trunk/libgo/aclocal.m4
trunk/libgo/config/libtool.m4
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/testsuite/Makefile.in

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.3 |9.0

--- Comment #11 from Joseph S. Myers  ---
Fixed for GCC 9 by updating the required automake version.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #10 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Oct 31 17:03:16 2018
New Revision: 265695

URL: https://gcc.gnu.org/viewcvs?rev=265695=gcc=rev
Log:
Update GCC to autoconf 2.69, automake 1.15.1 (PR bootstrap/82856).

This patch 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 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:
2018-10-31  Joseph Myers  

PR bootstrap/82856
* 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  

PR bootstrap/82856
* 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 

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.2 |8.3

--- Comment #9 from Jakub Jelinek  ---
GCC 8.2 has been released.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #8 from Jakub Jelinek  ---
GCC 8.1 has been released.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Nov 16 20:24:00 2017
New Revision: 254845

URL: https://gcc.gnu.org/viewcvs?rev=254845=gcc=rev
Log:
2017-11-16  Thomas Koenig  

PR bootstrap/82856
* doc/install.texi: Document incompatibility of Perl >=5.6.26
with the required version of automake 1.11.6.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 7 Nov 2017, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856
> 
> Thomas Koenig  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-11-07
> Summary|[8 Regression]  |--enable-maintainter-mode
>|--enable-maintainter-mode   |broken by incompatiblity of
>|broken by automake failure  |gcc's required automake and
>||modern Perl
>  Ever confirmed|0   |1
> 
> --- Comment #5 from Thomas Koenig  ---
> It seems that automake 1.15.1 fixed the issue.
> 
> This is not really a regression, it is just relying on an old version
> finally started to break things.
> 
> So, it seems it is finally time to update all the auto* tools
> for gcc. I don't think using a hand-patched version like in
> comment #3 is really an option.

Updating autotools is somewhat tedius but I guess if there's a volunteer 
stage3 would be still appropriate.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-07
Summary|[8 Regression]  |--enable-maintainter-mode
   |--enable-maintainter-mode   |broken by incompatiblity of
   |broken by automake failure  |gcc's required automake and
   ||modern Perl
 Ever confirmed|0   |1

--- Comment #5 from Thomas Koenig  ---
It seems that automake 1.15.1 fixed the issue.

This is not really a regression, it is just relying on an old version
finally started to break things.

So, it seems it is finally time to update all the auto* tools
for gcc. I don't think using a hand-patched version like in
comment #3 is really an option.