This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest
- From: Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Janne Blomqvist <blomqvist dot janne at gmail dot com>, Janne Blomqvist <jb at gcc dot gnu dot org>, Kai Tietz <ktietz at redhat dot com>, David Edelsohn <dje dot gcc at gmail dot com>, Paolo Bonzini <bonzini at gnu dot org>, DJ Delorie <dj at redhat dot com>, Nathanael Nerode <neroden at gcc dot gnu dot org>, Alexandre Oliva <aoliva at redhat dot com>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Jan-Benedict Glaw <jbglaw at lug-owl dot de>
- Date: Sun, 04 Jan 2015 20:20:40 +0100
- Subject: Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest
- Authentication-results: sourceware.org; auth=none
- References: <54942092 dot 7030208 at ssi-schaefer dot com> <CAO9iq9HfugCT0ZrLLfZ3pbsDr0pLwHE9EBENhJcwHybGVNGhnQ at mail dot gmail dot com>
(CC'ing build machinery maintainers, maybe I should have done this initially)
Am 2014-12-31 um 11:45 schrieb Janne Blomqvist:
> On Fri, Dec 19, 2014 at 2:56 PM, Michael Haubenwallner
> <michael.haubenwallner@ssi-schaefer.com> wrote:
>> On the way to prepare some (aix) libtool patch for toplevel libtool.m4
>> I've discovered that different versions of automake were used to generate
>> files across various libs:
>>
>> most libs: automake-1.11.1
>> libatomic r211747: automake-1.11.6
>> libgfortran r204654: automake-1.11.3
>> r215741: automake-1.11.6
>>
>> Doesn't feel like there were specific reasons to use newer versions,
>> but OTOH I've failed to find some docs on which versions to use, so
>> I'd be fine with updating others to 1.11.6 instead as well.
>
> I'm far from an autotools expert, but one justification for updating
> to 1.11.6 would be CVE-2012-3386, see
> https://lists.gnu.org/archive/html/automake/2012-07/msg00023.html .
>
> Whatever version we end up choosing, the docs should say it so that
> there won't be such misconceptions in the future, IMHO.
IMHO, changing an autotool's version in general should be up to (review by)
the build machinery maintainers.
And it should be done across the whole tree, not just for various subdirectories.
However, each update listed here feels like happened by accident, using the
version installed on the more or less up-to-date host OS.
Am 2014-12-28 um 05:20 schrieb Bernd Edlinger:
> On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote:
>> <text above>
>
> Michael proposes to change everything to automake-1.11.1.
> But the helper files "missing" and friends were updated to automake-1.14.1
> by:
>
> 2014-11-16 Jan-Benedict Glaw <jbglaw@lug-owl.de>
>
> * compile: Sync with upstream Automake.
> * depcomp: Ditto.
> * install-sh: Ditto.
> * missing: Ditto.
> * mkinstalldirs: Ditto.
> * ylwrap: Ditto.
>
>
> Actually I thought that was in preparation to move everything to automake 1.14.1
>
> If I see that right, calling automake without parameters does not touch these
> helper files, but "automake --add-missing --copy --force-missing" would replace
> them with the copy from the automake installation additionally to just rewriting the
> Makefile.in.
>
> I think we should have all automake files from the same version, either 1.11.1
> or 1.14.1.
>
> What do you think?
Updating to 1.14 might require more work like updating some .in files as well. I've
seen automake-1.11 being explicitly used, so for now we really want 1.11.6 eventually?
/haubi/