Update GCC to autoconf 2.69, automake 1.15.1

Thomas Koenig tkoenig@netcologne.de
Wed Oct 31 07:12:00 GMT 2018


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



More information about the Libstdc++ mailing list