GNU bug report logs - #20082
new warning from ar on rawhide systems

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: automake; Reported by: Eric Blake <eblake@HIDDEN>; dated Wed, 11 Mar 2015 16:08:02 UTC; Maintainer for automake is bug-automake@HIDDEN.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 29 Sep 2015 08:56:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 29 04:56:18 2015
Received: from localhost ([127.0.0.1]:47240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Zgqhu-00041B-I7
	for submit <at> debbugs.gnu.org; Tue, 29 Sep 2015 04:56:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36361)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Zgqhs-00040u-7M; Tue, 29 Sep 2015 04:56:17 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 by mx1.redhat.com (Postfix) with ESMTPS id D42A68A344;
 Tue, 29 Sep 2015 08:56:13 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-237.brq.redhat.com
 [10.34.4.237])
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t8T8uBar022975
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Tue, 29 Sep 2015 04:56:13 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-libtool@HIDDEN, 20082 <at> debbugs.gnu.org
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Tue, 29 Sep 2015 10:56:11 +0200
Message-ID: <6534791.kSHa0XPCMD@HIDDEN>
User-Agent: KMail/4.14.10 (Linux/4.2.1-300.fc23.x86_64+debug; KDE/4.14.11;
 x86_64; ; )
In-Reply-To: <11680087.Cd4Z9BCh61@HIDDEN>
References: <55006845.10402@HIDDEN>
 <3954257.lLEz5fDhO9@HIDDEN>
 <11680087.Cd4Z9BCh61@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, control <at> debbugs.gnu.org, eblake@HIDDEN,
 peda@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

close 19967 2.4.6.9-41812
--

On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote:
> > Not sure whether some review has been done, so pinging once more to get
> > some attention.  Otherwise I'll probably push those changes.
> 
> OK, I updated the patches a bit more and now just holding them in
> praiskup-ARFLAGS branch for a while.

ARFLAGS default has been fixed in gnulib recently, I've pushed this to
libtool.  Only automake looks like it needs a fix.

Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 1 Jul 2015 08:01:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 01 04:01:05 2015
Received: from localhost ([127.0.0.1]:35147 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZACx5-0004Bw-GV
	for submit <at> debbugs.gnu.org; Wed, 01 Jul 2015 04:01:04 -0400
Received: from mx1.redhat.com ([209.132.183.28]:47270)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1ZACwz-0004BR-9k; Wed, 01 Jul 2015 04:00:58 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (Postfix) with ESMTPS id D4FEDB82A9;
 Wed,  1 Jul 2015 08:00:55 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-221.brq.redhat.com
 [10.34.4.221])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t6180qr3028929
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Wed, 1 Jul 2015 04:00:54 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-libtool@HIDDEN
Subject: [gnulib PATCH]: new warning from ar on rawhide systems
Date: Wed, 01 Jul 2015 10:00:52 +0200
Message-ID: <1687514.YBB9xVk2LQ@HIDDEN>
User-Agent: KMail/4.14.9 (Linux/4.0.5-200.fc21.x86_64+debug; KDE/4.14.9; x86_64;
 ; )
In-Reply-To: <11680087.Cd4Z9BCh61@HIDDEN>
References: <55006845.10402@HIDDEN>
 <3954257.lLEz5fDhO9@HIDDEN>
 <11680087.Cd4Z9BCh61@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart3236019.CWpWYvIZJ2"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Spam-Score: -5.6 (-----)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, bug-gnulib@HIDDEN, eblake@HIDDEN,
 20082 <at> debbugs.gnu.org, peda@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.6 (-----)

This is a multi-part message in MIME format.

--nextPart3236019.CWpWYvIZJ2
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys:  I haven't done proper analysis yet.  Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project?  If yes, could we possibly at least set the ARFLAGS
> default value to 'cr' instead of 'cru'?  See [1,2] for context.

This becomes painfully complicated, sorry to bothering you - just trying
to make this ARFLAGS/AR_FLAGS mess resolved.  I would appreciate any help.

Seems like the gl_PROG_AR_RANLIB was added by commit 2b14869442bc.

Do you think the attached gnulib patches are reasonable then?  First makes
the gl_PROG_AR_RANLIB a bit more conservative and the second sets the
ARFLAGS default to 'cr'.

Pavel

--nextPart3236019.CWpWYvIZJ2
Content-Disposition: attachment; filename="0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch"

From 4631a59ef8edb1e499c13a72f61d318aa665bbad Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Wed, 1 Jul 2015 09:06:49 +0200
Subject: [PATCH 1/2] gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash

The gl_PROG_AR_RANLIB (it is always called by gl_EARLY) sets AR
and ARFLAGS variables.  Doing this unconditionally could brake
latter Automake's AM_PROG_AR invocation (at least it's
AC_CHECK_TOOLS call to detect 'ar' binary).

Original purpose of the gl_PROG_AR_RANLIB was only to handle the
Amsterdam Compiler Kit, so make the code to have effects only on
ACK, let the AM_PROG_AR decide other cases.

* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): AC_BEFORE AM_PROG_AR.
Set the AR/ARFLAGS to ACK defaults OR call AM_PROG_AR.  If neither
is possible, keep setting AR/ARFLAGS to reasonable defaults.
---
 m4/gnulib-common.m4 | 43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index b301abe..613e8d5 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -253,9 +253,10 @@ AC_DEFUN([gl_PROG_AR_RANLIB],
 [
   dnl Minix 3 comes with two toolchains: The Amsterdam Compiler Kit compiler
   dnl as "cc", and GCC as "gcc". They have different object file formats and
-  dnl library formats. In particular, the GNU binutils programs ar, ranlib
+  dnl library formats. In particular, the GNU binutils programs ar and ranlib
   dnl produce libraries that work only with gcc, not with cc.
   AC_REQUIRE([AC_PROG_CC])
+  AC_BEFORE([$0], [AM_PROG_AR])
   AC_CACHE_CHECK([for Minix Amsterdam compiler], [gl_cv_c_amsterdam_compiler],
     [
       AC_EGREP_CPP([Amsterdam],
@@ -267,25 +268,37 @@ Amsterdam
         [gl_cv_c_amsterdam_compiler=yes],
         [gl_cv_c_amsterdam_compiler=no])
     ])
-  if test -z "$AR"; then
-    if test $gl_cv_c_amsterdam_compiler = yes; then
+
+  dnl Don't compete with AM_PROG_AR's decission about AR/ARFLAGS if we are not
+  dnl building with __ACK__.
+  if test $gl_cv_c_amsterdam_compiler = yes; then
+    if test -z "$AR"; then
       AR='cc -c.a'
-      if test -z "$ARFLAGS"; then
-        ARFLAGS='-o'
-      fi
-    else
-      dnl Use the Automake-documented default values for AR and ARFLAGS,
-      dnl but prefer ${host}-ar over ar (useful for cross-compiling).
-      AC_CHECK_TOOL([AR], [ar], [ar])
-      if test -z "$ARFLAGS"; then
-        ARFLAGS='cru'
-      fi
     fi
-  else
     if test -z "$ARFLAGS"; then
-      ARFLAGS='cru'
+      ARFLAGS='-o'
     fi
+  else
+    dnl AM_PROG_AR was added in automake v1.11.2.  AM_PROG_AR does not AC_SUBST
+    dnl ARFLAGS variable (it is filed into Makefile.in directly by automake
+    dnl script on-demand, if not specified by ./configure of course).
+    dnl Don't AC_REQUIRE the AM_PROG_AR otherwise the code for __ACK__ above
+    dnl will be ignored.  Also, pay attention to call AM_PROG_AR in else block
+    dnl because AM_PROG_AR is written so it could re-set AR variable even for
+    dnl __ACK__.  It may seem like its easier to avoid calling the macro here,
+    dnl but we need to AC_SUBST both AR/ARFLAGS (thus those must have some good
+    dnl default value and automake should usually know them).
+    m4_ifdef([AM_PROG_AR], [AM_PROG_AR], [:])
   fi
+
+  dnl In case the code above have not helped with setting AR/ARFLAGS, use
+  dnl Automake-documented default values for AR and ARFLAGS, but prefer
+  dnl ${host}-ar over ar (useful for cross-compiling).
+  AC_CHECK_TOOL([AR], [ar], [ar])
+  if test -z "$ARFLAGS"; then
+    ARFLAGS='cru'
+  fi
+
   AC_SUBST([AR])
   AC_SUBST([ARFLAGS])
   if test -z "$RANLIB"; then
-- 
2.1.0


--nextPart3236019.CWpWYvIZJ2
Content-Disposition: attachment; filename="0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch"

From 64d95effe459f7e7b02834a6ad1d7e5e092581a0 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Wed, 1 Jul 2015 09:38:35 +0200
Subject: [PATCH 2/2] gnulib-common.m4: change the ARFLAGS default to 'cr'

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with previous autotools long time
working default AR{_,}FLAGS=cru causes warnings on such
installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it will disable the 'u', with the benefit of having
rather a bit more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silent such warnings.

* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): Set ARFLAGS='cr' if not
set already.
---
 m4/gnulib-common.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 613e8d5..34d0f20 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -296,7 +296,7 @@ Amsterdam
   dnl ${host}-ar over ar (useful for cross-compiling).
   AC_CHECK_TOOL([AR], [ar], [ar])
   if test -z "$ARFLAGS"; then
-    ARFLAGS='cru'
+    ARFLAGS='cr'
   fi
 
   AC_SUBST([AR])
-- 
2.1.0


--nextPart3236019.CWpWYvIZJ2--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 1 Jul 2015 08:01:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 01 04:01:20 2015
Received: from localhost ([127.0.0.1]:35150 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ZACxL-0004Cd-7h
	for submit <at> debbugs.gnu.org; Wed, 01 Jul 2015 04:01:20 -0400
Received: from eggs.gnu.org ([208.118.235.92]:48773)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>) id 1ZACxJ-0004CR-AI
 for submit <at> debbugs.gnu.org; Wed, 01 Jul 2015 04:01:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1ZACxC-0008O0-J7
 for submit <at> debbugs.gnu.org; Wed, 01 Jul 2015 04:01:11 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:47653)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1ZACxC-0008Np-F6
 for submit <at> debbugs.gnu.org; Wed, 01 Jul 2015 04:01:10 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33966)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1ZACx9-00086U-71
 for bug-libtool@HIDDEN; Wed, 01 Jul 2015 04:01:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1ZACx7-0008EE-IM
 for bug-libtool@HIDDEN; Wed, 01 Jul 2015 04:01:07 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36458)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>)
 id 1ZACwz-0008Cd-FP; Wed, 01 Jul 2015 04:00:57 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (Postfix) with ESMTPS id D4FEDB82A9;
 Wed,  1 Jul 2015 08:00:55 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-221.brq.redhat.com
 [10.34.4.221])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t6180qr3028929
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Wed, 1 Jul 2015 04:00:54 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-libtool@HIDDEN
Subject: [gnulib PATCH]: new warning from ar on rawhide systems
Date: Wed, 01 Jul 2015 10:00:52 +0200
Message-ID: <1687514.YBB9xVk2LQ@HIDDEN>
User-Agent: KMail/4.14.9 (Linux/4.0.5-200.fc21.x86_64+debug; KDE/4.14.9; x86_64;
 ; )
In-Reply-To: <11680087.Cd4Z9BCh61@HIDDEN>
References: <55006845.10402@HIDDEN>
 <3954257.lLEz5fDhO9@HIDDEN>
 <11680087.Cd4Z9BCh61@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart3236019.CWpWYvIZJ2"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
Cc: 19967 <at> debbugs.gnu.org, bug-gnulib@HIDDEN, eblake@HIDDEN,
 20082 <at> debbugs.gnu.org, peda@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.

--nextPart3236019.CWpWYvIZJ2
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys:  I haven't done proper analysis yet.  Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project?  If yes, could we possibly at least set the ARFLAGS
> default value to 'cr' instead of 'cru'?  See [1,2] for context.

This becomes painfully complicated, sorry to bothering you - just trying
to make this ARFLAGS/AR_FLAGS mess resolved.  I would appreciate any help.

Seems like the gl_PROG_AR_RANLIB was added by commit 2b14869442bc.

Do you think the attached gnulib patches are reasonable then?  First makes
the gl_PROG_AR_RANLIB a bit more conservative and the second sets the
ARFLAGS default to 'cr'.

Pavel

--nextPart3236019.CWpWYvIZJ2
Content-Disposition: attachment; filename="0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch"

From 4631a59ef8edb1e499c13a72f61d318aa665bbad Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Wed, 1 Jul 2015 09:06:49 +0200
Subject: [PATCH 1/2] gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash

The gl_PROG_AR_RANLIB (it is always called by gl_EARLY) sets AR
and ARFLAGS variables.  Doing this unconditionally could brake
latter Automake's AM_PROG_AR invocation (at least it's
AC_CHECK_TOOLS call to detect 'ar' binary).

Original purpose of the gl_PROG_AR_RANLIB was only to handle the
Amsterdam Compiler Kit, so make the code to have effects only on
ACK, let the AM_PROG_AR decide other cases.

* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): AC_BEFORE AM_PROG_AR.
Set the AR/ARFLAGS to ACK defaults OR call AM_PROG_AR.  If neither
is possible, keep setting AR/ARFLAGS to reasonable defaults.
---
 m4/gnulib-common.m4 | 43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index b301abe..613e8d5 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -253,9 +253,10 @@ AC_DEFUN([gl_PROG_AR_RANLIB],
 [
   dnl Minix 3 comes with two toolchains: The Amsterdam Compiler Kit compiler
   dnl as "cc", and GCC as "gcc". They have different object file formats and
-  dnl library formats. In particular, the GNU binutils programs ar, ranlib
+  dnl library formats. In particular, the GNU binutils programs ar and ranlib
   dnl produce libraries that work only with gcc, not with cc.
   AC_REQUIRE([AC_PROG_CC])
+  AC_BEFORE([$0], [AM_PROG_AR])
   AC_CACHE_CHECK([for Minix Amsterdam compiler], [gl_cv_c_amsterdam_compiler],
     [
       AC_EGREP_CPP([Amsterdam],
@@ -267,25 +268,37 @@ Amsterdam
         [gl_cv_c_amsterdam_compiler=yes],
         [gl_cv_c_amsterdam_compiler=no])
     ])
-  if test -z "$AR"; then
-    if test $gl_cv_c_amsterdam_compiler = yes; then
+
+  dnl Don't compete with AM_PROG_AR's decission about AR/ARFLAGS if we are not
+  dnl building with __ACK__.
+  if test $gl_cv_c_amsterdam_compiler = yes; then
+    if test -z "$AR"; then
       AR='cc -c.a'
-      if test -z "$ARFLAGS"; then
-        ARFLAGS='-o'
-      fi
-    else
-      dnl Use the Automake-documented default values for AR and ARFLAGS,
-      dnl but prefer ${host}-ar over ar (useful for cross-compiling).
-      AC_CHECK_TOOL([AR], [ar], [ar])
-      if test -z "$ARFLAGS"; then
-        ARFLAGS='cru'
-      fi
     fi
-  else
     if test -z "$ARFLAGS"; then
-      ARFLAGS='cru'
+      ARFLAGS='-o'
     fi
+  else
+    dnl AM_PROG_AR was added in automake v1.11.2.  AM_PROG_AR does not AC_SUBST
+    dnl ARFLAGS variable (it is filed into Makefile.in directly by automake
+    dnl script on-demand, if not specified by ./configure of course).
+    dnl Don't AC_REQUIRE the AM_PROG_AR otherwise the code for __ACK__ above
+    dnl will be ignored.  Also, pay attention to call AM_PROG_AR in else block
+    dnl because AM_PROG_AR is written so it could re-set AR variable even for
+    dnl __ACK__.  It may seem like its easier to avoid calling the macro here,
+    dnl but we need to AC_SUBST both AR/ARFLAGS (thus those must have some good
+    dnl default value and automake should usually know them).
+    m4_ifdef([AM_PROG_AR], [AM_PROG_AR], [:])
   fi
+
+  dnl In case the code above have not helped with setting AR/ARFLAGS, use
+  dnl Automake-documented default values for AR and ARFLAGS, but prefer
+  dnl ${host}-ar over ar (useful for cross-compiling).
+  AC_CHECK_TOOL([AR], [ar], [ar])
+  if test -z "$ARFLAGS"; then
+    ARFLAGS='cru'
+  fi
+
   AC_SUBST([AR])
   AC_SUBST([ARFLAGS])
   if test -z "$RANLIB"; then
-- 
2.1.0


--nextPart3236019.CWpWYvIZJ2
Content-Disposition: attachment; filename="0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch"

From 64d95effe459f7e7b02834a6ad1d7e5e092581a0 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Wed, 1 Jul 2015 09:38:35 +0200
Subject: [PATCH 2/2] gnulib-common.m4: change the ARFLAGS default to 'cr'

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with previous autotools long time
working default AR{_,}FLAGS=cru causes warnings on such
installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it will disable the 'u', with the benefit of having
rather a bit more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silent such warnings.

* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): Set ARFLAGS='cr' if not
set already.
---
 m4/gnulib-common.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 613e8d5..34d0f20 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -296,7 +296,7 @@ Amsterdam
   dnl ${host}-ar over ar (useful for cross-compiling).
   AC_CHECK_TOOL([AR], [ar], [ar])
   if test -z "$ARFLAGS"; then
-    ARFLAGS='cru'
+    ARFLAGS='cr'
   fi
 
   AC_SUBST([AR])
-- 
2.1.0


--nextPart3236019.CWpWYvIZJ2--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 25 Jun 2015 14:50:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 25 10:50:23 2015
Received: from localhost ([127.0.0.1]:57358 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Z88Tt-0004MD-TC
	for submit <at> debbugs.gnu.org; Thu, 25 Jun 2015 10:50:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38530)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Z88Tp-0004Lx-0h; Thu, 25 Jun 2015 10:50:18 -0400
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
 (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
 by mx1.redhat.com (Postfix) with ESMTPS id AC86E3790FB;
 Thu, 25 Jun 2015 14:50:15 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-117.brq.redhat.com
 [10.34.4.117])
 by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t5PEoCXK019754
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Thu, 25 Jun 2015 10:50:14 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-libtool@HIDDEN
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Thu, 25 Jun 2015 16:50:12 +0200
Message-ID: <11680087.Cd4Z9BCh61@HIDDEN>
User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64+debug; KDE/4.14.9; x86_64;
 ; )
In-Reply-To: <3954257.lLEz5fDhO9@HIDDEN>
References: <55006845.10402@HIDDEN>
 <33243489.DCmb3o5UTg@HIDDEN>
 <3954257.lLEz5fDhO9@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Spam-Score: -6.4 (------)
X-Debbugs-Envelope-To: 20082
Cc: bug-gnulib@HIDDEN, 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org,
 eblake@HIDDEN, peda@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.4 (------)

On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote:
> Not sure whether some review has been done, so pinging once more to get
> some attention.  Otherwise I'll probably push those changes.

OK, I updated the patches a bit more and now just holding them in
praiskup-ARFLAGS branch for a while.

I noticed that at this moment 'gnulib' decides what will be the default
ARFLAGS, not libtool (since the time libtool started to be dependant on
gnulib -- and thus calls automatically GL_EARLY).

To gnulib guys:  I haven't done proper analysis yet.  Is the
gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
dependant project?  If yes, could we possibly at least set the ARFLAGS
default value to 'cr' instead of 'cru'?  See [1,2] for context.

From libtool POV I'm not sure what is correct approach, should we let
gnulib do the decission about ARFLAGS, or should I rather somehow by-pass
the gl_PROG_AR_RANLIB.  Similarly automake (theoretically, AFAIK it does
not depend on gnulib yet), there is also some logic regarding ARFLAGS
variable..

[1] https://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html
[2] https://lists.gnu.org/archive/html/bug-automake/2015-03/msg00004.html

Thanks, Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 17 Jun 2015 07:22:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 17 03:22:41 2015
Received: from localhost ([127.0.0.1]:56779 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Z57gH-0003wl-F3
	for submit <at> debbugs.gnu.org; Wed, 17 Jun 2015 03:22:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33384)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Z57gD-0003wP-D7; Wed, 17 Jun 2015 03:22:38 -0400
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
 (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
 by mx1.redhat.com (Postfix) with ESMTPS id 40E572B9DE8;
 Wed, 17 Jun 2015 07:22:35 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-117.brq.redhat.com
 [10.34.4.117])
 by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t5H7MWg1002307
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Wed, 17 Jun 2015 03:22:34 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-libtool@HIDDEN
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Wed, 17 Jun 2015 09:22:31 +0200
Message-ID: <3954257.lLEz5fDhO9@HIDDEN>
User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64+debug; KDE/4.14.9; x86_64;
 ; )
In-Reply-To: <33243489.DCmb3o5UTg@HIDDEN>
References: <55006845.10402@HIDDEN> <55312FDD.50704@HIDDEN>
 <33243489.DCmb3o5UTg@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Spam-Score: -5.6 (-----)
X-Debbugs-Envelope-To: 20082
Cc: Peter Rosin <peda@HIDDEN>, 20082 <at> debbugs.gnu.org,
 Eric Blake <eblake@HIDDEN>, 19967 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.6 (-----)

On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:
> On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > if somebody could comment,
> > 
> > Microsofts archiver (lib.exe) uses a syntax like:
> > 
> >   lib -extract:file.o archive.lib
> > 
> > where -extract: was thought to be the content of $AR_FLAGS.
> > 
> > But since then, I added the ar-lib helper to Automake, which hides
> > these brain-damaged flags that lib expects.
> 
> Thanks for the info, Peter.
> 
> Any objections against attached patches?

Not sure whether some review has been done, so pinging once more to get
some attention.  Otherwise I'll probably push those changes.

Thanks, Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 2 Jun 2015 14:23:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 02 10:23:17 2015
Received: from localhost ([127.0.0.1]:37701 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Yzn64-0000qK-Lx
	for submit <at> debbugs.gnu.org; Tue, 02 Jun 2015 10:23:17 -0400
Received: from eggs.gnu.org ([208.118.235.92]:45492)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>) id 1Yzn62-0000q5-QM
 for submit <at> debbugs.gnu.org; Tue, 02 Jun 2015 10:23:15 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1Yzn5p-0000j7-TZ
 for submit <at> debbugs.gnu.org; Tue, 02 Jun 2015 10:23:09 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:55840)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1Yzn5p-0000j0-Q4
 for submit <at> debbugs.gnu.org; Tue, 02 Jun 2015 10:23:01 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58926)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1Yzn5o-0006Lr-5V
 for bug-automake@HIDDEN; Tue, 02 Jun 2015 10:23:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1Yzn5m-0000gY-LN
 for bug-automake@HIDDEN; Tue, 02 Jun 2015 10:23:00 -0400
Received: from mx1.redhat.com ([209.132.183.28]:46181)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>)
 id 1Yzn5h-0000eO-PE; Tue, 02 Jun 2015 10:22:53 -0400
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
 (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
 by mx1.redhat.com (Postfix) with ESMTPS id BB1922B6495;
 Tue,  2 Jun 2015 14:22:52 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-196.brq.redhat.com
 [10.34.4.196])
 by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t52EMoaB032261
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Tue, 2 Jun 2015 10:22:51 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-automake@HIDDEN
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Tue, 02 Jun 2015 16:22:50 +0200
Message-ID: <2076643.go2A7Hs5WS@HIDDEN>
User-Agent: KMail/4.14.7 (Linux/4.0.4-201.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <33243489.DCmb3o5UTg@HIDDEN>
References: <55006845.10402@HIDDEN> <55312FDD.50704@HIDDEN>
 <33243489.DCmb3o5UTg@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart3794147.JVxya1du4i"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
Cc: Peter Rosin <peda@HIDDEN>, 20082 <at> debbugs.gnu.org,
 Eric Blake <eblake@HIDDEN>, Automake Patches <automake-patches@HIDDEN>,
 19967 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.

--nextPart3794147.JVxya1du4i
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:
> On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > if somebody could comment,
> > 
> > Microsofts archiver (lib.exe) uses a syntax like:
> > 
> >   lib -extract:file.o archive.lib
> > 
> > where -extract: was thought to be the content of $AR_FLAGS.
> > 
> > But since then, I added the ar-lib helper to Automake, which hides
> > these brain-damaged flags that lib expects.
> 
> Thanks for the info, Peter.

And the patch against Automake attached now, sorry for the delay.

Pavel

--nextPart3794147.JVxya1du4i
Content-Disposition: attachment; filename="0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch"

From e384778530df13e3dbd3cc92fd6bd5a53d75b64f Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Tue, 2 Jun 2015 15:29:22 +0200
Subject: [PATCH] ARFLAGS: use 'cr' instead of 'cru' by default

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silent such warnings.

Fixes bug#20082.  Reported by Eric Blake.

* bin/autoamke.in (handle_libraries): Use 'ARFLAGS=cr' by default.
* doc/automake.texi (Building a library): Mention the changed
ARFLAGS default.
(@c LocalWords): Replace 'cru' with 'cr'.
* m4/ar-lib.m4 (AM_PROG_AR): Cut out 'cru' string into separate
ARFLAGS variable with new default 'cr'.
* NEWS: Document.
---
 NEWS              | 4 ++++
 bin/automake.in   | 2 +-
 doc/automake.texi | 4 ++--
 m4/ar-lib.m4      | 3 ++-
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 9f76c1f..b611868 100644
--- a/NEWS
+++ b/NEWS
@@ -103,6 +103,10 @@ New in 1.16:
 
     This was the second part of automake bug#13928.
 
+* Miscellaneous changes:
+
+  - Changed the default value of $ARFLAGS from 'cru' to 'cr'.
+
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 New in 1.15:
diff --git a/bin/automake.in b/bin/automake.in
index 355d7ff..0c29184 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2538,7 +2538,7 @@ sub handle_libraries ()
     }
 
   define_variable ('AR', 'ar', INTERNAL);
-  define_variable ('ARFLAGS', 'cru', INTERNAL);
+  define_variable ('ARFLAGS', 'cr', INTERNAL);
   define_verbose_tagvar ('AR');
 
   foreach my $pair (@liblist)
diff --git a/doc/automake.texi b/doc/automake.texi
index e46212f..bc1f032 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5061,7 +5061,7 @@ library and the list of objects, and finally by calling
 @code{RANLIB} (Automake will complain otherwise).  You should also
 call @code{AM_PROG_AR} to define @code{AR}, in order to support unusual
 archivers such as Microsoft lib.  @code{ARFLAGS} will default to
-@code{cru}; you can override this variable by setting it in your
+@code{cr}; you can override this variable by setting it in your
 @file{Makefile.am} or by @code{AC_SUBST}ing it from your
 @file{configure.ac}.  You can override the @code{AR} variable by
 defining a per-library @code{maude_AR} variable (@pxref{Program and
@@ -13162,7 +13162,7 @@ suite failures, please attach the @file{test-suite.log} file.
 @c  LocalWords:  Miller's installable includedir inc pkgdata EXEEXT libexec bsd
 @c  LocalWords:  pkglib libexecdir prog libcpio cpio's dlopen dlpreopen linux
 @c  LocalWords:  subsubsection OBJEXT esac lib LTLIBRARIES liblob LIBADD AR ar
-@c  LocalWords:  ARFLAGS cru ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
+@c  LocalWords:  ARFLAGS cr ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
 @c  LocalWords:  libmaude CCLD CXXFLAGS FFLAGS LFLAGS OBJCFLAGS RFLAGS DEFS cc
 @c  LocalWords:  OBJCXXFLAGS
 @c  LocalWords:  SHORTNAME vtable srcdir nostdinc basename yxx cxx ll lxx gdb
diff --git a/m4/ar-lib.m4 b/m4/ar-lib.m4
index 914b21b..767a76c 100644
--- a/m4/ar-lib.m4
+++ b/m4/ar-lib.m4
@@ -17,12 +17,13 @@ AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([ar-lib])dnl
 AC_CHECK_TOOLS([AR], [ar lib "link -lib"], [false])
 : ${AR=ar}
+: ${ARFLAGS=cr}
 
 AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface],
   [AC_LANG_PUSH([C])
    am_cv_ar_interface=ar
    AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int some_variable = 0;]])],
-     [am_ar_try='$AR cru libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+     [am_ar_try='$AR $ARFLAGS libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
       AC_TRY_EVAL([am_ar_try])
       if test "$ac_status" -eq 0; then
         am_cv_ar_interface=ar
-- 
2.1.0


--nextPart3794147.JVxya1du4i--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 2 Jun 2015 14:22:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 02 10:22:58 2015
Received: from localhost ([127.0.0.1]:37696 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Yzn5l-0000oz-J9
	for submit <at> debbugs.gnu.org; Tue, 02 Jun 2015 10:22:58 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33439)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Yzn5i-0000ok-1j; Tue, 02 Jun 2015 10:22:55 -0400
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
 (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
 by mx1.redhat.com (Postfix) with ESMTPS id BB1922B6495;
 Tue,  2 Jun 2015 14:22:52 +0000 (UTC)
Received: from nb.usersys.redhat.com (unused-4-196.brq.redhat.com
 [10.34.4.196])
 by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t52EMoaB032261
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Tue, 2 Jun 2015 10:22:51 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-automake@HIDDEN
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Tue, 02 Jun 2015 16:22:50 +0200
Message-ID: <2076643.go2A7Hs5WS@HIDDEN>
User-Agent: KMail/4.14.7 (Linux/4.0.4-201.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <33243489.DCmb3o5UTg@HIDDEN>
References: <55006845.10402@HIDDEN> <55312FDD.50704@HIDDEN>
 <33243489.DCmb3o5UTg@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart3794147.JVxya1du4i"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: Peter Rosin <peda@HIDDEN>, 20082 <at> debbugs.gnu.org,
 Eric Blake <eblake@HIDDEN>, Automake Patches <automake-patches@HIDDEN>,
 19967 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.

--nextPart3794147.JVxya1du4i
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:
> On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > if somebody could comment,
> > 
> > Microsofts archiver (lib.exe) uses a syntax like:
> > 
> >   lib -extract:file.o archive.lib
> > 
> > where -extract: was thought to be the content of $AR_FLAGS.
> > 
> > But since then, I added the ar-lib helper to Automake, which hides
> > these brain-damaged flags that lib expects.
> 
> Thanks for the info, Peter.

And the patch against Automake attached now, sorry for the delay.

Pavel

--nextPart3794147.JVxya1du4i
Content-Disposition: attachment; filename="0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch"

From e384778530df13e3dbd3cc92fd6bd5a53d75b64f Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Tue, 2 Jun 2015 15:29:22 +0200
Subject: [PATCH] ARFLAGS: use 'cr' instead of 'cru' by default

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silent such warnings.

Fixes bug#20082.  Reported by Eric Blake.

* bin/autoamke.in (handle_libraries): Use 'ARFLAGS=cr' by default.
* doc/automake.texi (Building a library): Mention the changed
ARFLAGS default.
(@c LocalWords): Replace 'cru' with 'cr'.
* m4/ar-lib.m4 (AM_PROG_AR): Cut out 'cru' string into separate
ARFLAGS variable with new default 'cr'.
* NEWS: Document.
---
 NEWS              | 4 ++++
 bin/automake.in   | 2 +-
 doc/automake.texi | 4 ++--
 m4/ar-lib.m4      | 3 ++-
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 9f76c1f..b611868 100644
--- a/NEWS
+++ b/NEWS
@@ -103,6 +103,10 @@ New in 1.16:
 
     This was the second part of automake bug#13928.
 
+* Miscellaneous changes:
+
+  - Changed the default value of $ARFLAGS from 'cru' to 'cr'.
+
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 New in 1.15:
diff --git a/bin/automake.in b/bin/automake.in
index 355d7ff..0c29184 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2538,7 +2538,7 @@ sub handle_libraries ()
     }
 
   define_variable ('AR', 'ar', INTERNAL);
-  define_variable ('ARFLAGS', 'cru', INTERNAL);
+  define_variable ('ARFLAGS', 'cr', INTERNAL);
   define_verbose_tagvar ('AR');
 
   foreach my $pair (@liblist)
diff --git a/doc/automake.texi b/doc/automake.texi
index e46212f..bc1f032 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5061,7 +5061,7 @@ library and the list of objects, and finally by calling
 @code{RANLIB} (Automake will complain otherwise).  You should also
 call @code{AM_PROG_AR} to define @code{AR}, in order to support unusual
 archivers such as Microsoft lib.  @code{ARFLAGS} will default to
-@code{cru}; you can override this variable by setting it in your
+@code{cr}; you can override this variable by setting it in your
 @file{Makefile.am} or by @code{AC_SUBST}ing it from your
 @file{configure.ac}.  You can override the @code{AR} variable by
 defining a per-library @code{maude_AR} variable (@pxref{Program and
@@ -13162,7 +13162,7 @@ suite failures, please attach the @file{test-suite.log} file.
 @c  LocalWords:  Miller's installable includedir inc pkgdata EXEEXT libexec bsd
 @c  LocalWords:  pkglib libexecdir prog libcpio cpio's dlopen dlpreopen linux
 @c  LocalWords:  subsubsection OBJEXT esac lib LTLIBRARIES liblob LIBADD AR ar
-@c  LocalWords:  ARFLAGS cru ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
+@c  LocalWords:  ARFLAGS cr ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
 @c  LocalWords:  libmaude CCLD CXXFLAGS FFLAGS LFLAGS OBJCFLAGS RFLAGS DEFS cc
 @c  LocalWords:  OBJCXXFLAGS
 @c  LocalWords:  SHORTNAME vtable srcdir nostdinc basename yxx cxx ll lxx gdb
diff --git a/m4/ar-lib.m4 b/m4/ar-lib.m4
index 914b21b..767a76c 100644
--- a/m4/ar-lib.m4
+++ b/m4/ar-lib.m4
@@ -17,12 +17,13 @@ AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([ar-lib])dnl
 AC_CHECK_TOOLS([AR], [ar lib "link -lib"], [false])
 : ${AR=ar}
+: ${ARFLAGS=cr}
 
 AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface],
   [AC_LANG_PUSH([C])
    am_cv_ar_interface=ar
    AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int some_variable = 0;]])],
-     [am_ar_try='$AR cru libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+     [am_ar_try='$AR $ARFLAGS libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
       AC_TRY_EVAL([am_ar_try])
       if test "$ac_status" -eq 0; then
         am_cv_ar_interface=ar
-- 
2.1.0


--nextPart3794147.JVxya1du4i--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 18 Apr 2015 10:47:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 06:47:34 2015
Received: from localhost ([127.0.0.1]:59617 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YjQHd-0006Oi-63
	for submit <at> debbugs.gnu.org; Sat, 18 Apr 2015 06:47:33 -0400
Received: from mx1.redhat.com ([209.132.183.28]:47911)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1YjQHZ-0006OQ-IA; Sat, 18 Apr 2015 06:47:30 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 by mx1.redhat.com (Postfix) with ESMTPS id 056058EA4C;
 Sat, 18 Apr 2015 10:47:26 +0000 (UTC)
Received: from nb.usersys.redhat.com (ovpn-200-46.brq.redhat.com
 [10.40.200.46])
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t3I9oWXw021209
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Sat, 18 Apr 2015 05:50:34 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: Peter Rosin <peda@HIDDEN>
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Sat, 18 Apr 2015 11:50:31 +0200
Message-ID: <33243489.DCmb3o5UTg@HIDDEN>
User-Agent: KMail/4.14.6 (Linux/3.19.3-200.fc21.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <55312FDD.50704@HIDDEN>
References: <55006845.10402@HIDDEN>
 <2462821.S22axYa0uW@HIDDEN> <55312FDD.50704@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart4584029.ZNY48Cg3c8"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, Eric Blake <eblake@HIDDEN>,
 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.

--nextPart4584029.ZNY48Cg3c8
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> On 2015-04-17 17:54, Pavel Raiskup wrote:
> > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > if somebody could comment,
> 
> Microsofts archiver (lib.exe) uses a syntax like:
> 
>   lib -extract:file.o archive.lib
> 
> where -extract: was thought to be the content of $AR_FLAGS.
> 
> But since then, I added the ar-lib helper to Automake, which hides
> these brain-damaged flags that lib expects.

Thanks for the info, Peter.

Any objections against attached patches?

Pavel

--nextPart4584029.ZNY48Cg3c8
Content-Disposition: attachment; filename="0001-libool.m4-incorporate-ARFLAGS-variable.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-libool.m4-incorporate-ARFLAGS-variable.patch"

From 5e24b9305a1c1a32f171b6801597a6d335cea8fa Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Fri, 17 Apr 2015 15:05:42 +0200
Subject: [PATCH 1/2] libool.m4: incorporate ARFLAGS variable

Libtool has used $AR_FLAGS since 2000-05-29 commit
8300de4c54e6f04f0d, Automake ARFLAGS since 2003-04-06 commit
a71b3490639831ca.  Even though ARFLAGS is younger, it sounds like
better naming according GNU Coding Standards.

Related to bug#20082.

* m4/libtool.m4 (_LT_PROG_AR): Start using ARFLAGS variable.
(lt_ar_flags): New _LT_DECL'ed variable to hold the configure-time
value of ARFLAGS.
(AR_FLAGS): Be sensitive to ARFLAGS env variable.  Reuse the
$lt_ar_flags during libtool runtime to set the default value.
* NEWS: Document.
---
 NEWS          |  5 +++++
 m4/libtool.m4 | 17 +++++++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index c5c9023..142d821 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** New features:
+
+  - Libtool script now supports (configure-time and runtime) ARFLAGS
+    variable, which obsoletes AR_FLAGS.  This is due to naming conventions
+    among other *FLAGS and to be consistent with Automake's ARFLAGS.
 
 * Noteworthy changes in release 2.4.6 (2015-02-15) [stable]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index a3bc337..26b7530 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1493,9 +1493,22 @@ need_locks=$enable_libtool_lock
 m4_defun([_LT_PROG_AR],
 [AC_CHECK_TOOLS(AR, [ar], false)
 : ${AR=ar}
-: ${AR_FLAGS=cru}
 _LT_DECL([], [AR], [1], [The archiver])
-_LT_DECL([], [AR_FLAGS], [1], [Flags to create an archive])
+
+# Use ARFLAGS variable as AR's operation code to sync the variable naming with
+# Automake.  If both AR_FLAGS and ARFLAGS are specified, AR_FLAGS should have
+# higher priority because thats what people were doing historically (setting
+# ARFLAGS for automake and AR_FLAGS for libtool).  FIXME: Make the AR_FLAGS
+# variable obsoleted/removed.
+
+: ${AR_FLAGS=${ARFLAGS-cru}}
+lt_ar_flags="$AR_FLAGS"
+_LT_DECL([], [lt_ar_flags], [0], [Flags to create an archive (by configure)])
+
+# Make AR_FLAGS overridable by 'make ARFLAGS='.  Don't try to run-time override
+# by AR_FLAGS because that was never working and AR_FLAGS is about to die.
+_LT_DECL([], [AR_FLAGS], [\${ARFLAGS-"\$lt_ar_flags"}],
+         [Flags to create an archive])
 
 AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file],
   [lt_cv_ar_at_file=no
-- 
2.1.0


--nextPart4584029.ZNY48Cg3c8
Content-Disposition: attachment; filename="0002-ARFLAGS-use-cr-instead-of-cru-by-default.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0002-ARFLAGS-use-cr-instead-of-cru-by-default.patch"

From ea7619e81fc839634b38a9459e6b69026ebbe6d7 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Fri, 17 Apr 2015 16:54:58 +0200
Subject: [PATCH 2/2] ARFLAGS: use 'cr' instead of 'cru' by default

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Libtool's ARFLAGS default, just to silent such warnings.

Fixes bug#19967.  Reported by Eric Blake.

* m4/libtool.m4 (_LT_PROG_AR): Default AR_FLAGS to 'cr'.
(_LT_REQUIRED_DARWIN_CHECKS): Use $AR_FLAGS instead 'cru' string.
* doc/libtool.texi: Do 's/ar cru/ar cr/' in whole documentation,
to not document something which is not done by libtool.
* NEWS: Document.
---
 NEWS             |  4 ++++
 doc/libtool.texi | 10 +++++-----
 m4/libtool.m4    |  6 +++---
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/NEWS b/NEWS
index 142d821..e4d75ff 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,10 @@ NEWS - list of user-visible changes between releases of GNU Libtool
     variable, which obsoletes AR_FLAGS.  This is due to naming conventions
     among other *FLAGS and to be consistent with Automake's ARFLAGS.
 
+** Important incompatible changes:
+
+  - Libtool changed ARFLAGS/AR_FLAGS default from 'cru' to 'cr'
+
 * Noteworthy changes in release 2.4.6 (2015-02-15) [stable]
 
 ** New features:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 0298627..4c664bb 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -602,7 +602,7 @@ Without libtool, the programmer would invoke the @command{ar} command to
 create a static library:
 
 @example
-burger$ @kbd{ar cru libhello.a hello.o foo.o}
+burger$ @kbd{ar cr libhello.a hello.o foo.o}
 burger$
 @end example
 
@@ -632,7 +632,7 @@ libtool are the same ones you would use to produce an executable named
 a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o}
 *** Warning: Linking the shared library libhello.la against the
 *** non-libtool objects foo.o hello.o is not portable!
-ar cru .libs/libhello.a
+ar cr .libs/libhello.a
 ranlib .libs/libhello.a
 creating libhello.la
 (cd .libs && rm -f libhello.la && ln -s ../libhello.la libhello.la)
@@ -662,7 +662,7 @@ archive, not a shared library (@pxref{Static libraries}).}:
 @example
 a23$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
                 -rpath /usr/local/lib -lm}
-ar cru @value{objdir}/libhello.a foo.o hello.o
+ar cr @value{objdir}/libhello.a foo.o hello.o
 ranlib @value{objdir}/libhello.a
 creating libhello.la
 (cd @value{objdir} && rm -f libhello.la && ln -s ../libhello.la libhello.la)
@@ -676,7 +676,7 @@ burger$ @kbd{libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
                 -rpath /usr/local/lib -lm}
 rm -fr  @value{objdir}/libhello.a @value{objdir}/libhello.la
 ld -Bshareable -o @value{objdir}/libhello.so.0.0 @value{objdir}/foo.o @value{objdir}/hello.o -lm
-ar cru @value{objdir}/libhello.a foo.o hello.o
+ar cr @value{objdir}/libhello.a foo.o hello.o
 ranlib @value{objdir}/libhello.a
 creating libhello.la
 (cd @value{objdir} && rm -f libhello.la && ln -s ../libhello.la libhello.la)
@@ -6001,7 +6001,7 @@ in cases where it is necessary.
 @subsection Archivers
 
 On all known systems, building a static library can be accomplished by
-running @kbd{ar cru lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}},
+running @kbd{ar cr lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}},
 where the @file{.a} file is the output library, and each @file{.o} file is an
 object file.
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 26b7530..e1674f5 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1042,8 +1042,8 @@ int forced_loaded() { return 2;}
 _LT_EOF
       echo "$LTCC $LTCFLAGS -c -o conftest.o conftest.c" >&AS_MESSAGE_LOG_FD
       $LTCC $LTCFLAGS -c -o conftest.o conftest.c 2>&AS_MESSAGE_LOG_FD
-      echo "$AR cru libconftest.a conftest.o" >&AS_MESSAGE_LOG_FD
-      $AR cru libconftest.a conftest.o 2>&AS_MESSAGE_LOG_FD
+      echo "$AR $AR_FLAGS libconftest.a conftest.o" >&AS_MESSAGE_LOG_FD
+      $AR $AR_FLAGS libconftest.a conftest.o 2>&AS_MESSAGE_LOG_FD
       echo "$RANLIB libconftest.a" >&AS_MESSAGE_LOG_FD
       $RANLIB libconftest.a 2>&AS_MESSAGE_LOG_FD
       cat > conftest.c << _LT_EOF
@@ -1501,7 +1501,7 @@ _LT_DECL([], [AR], [1], [The archiver])
 # ARFLAGS for automake and AR_FLAGS for libtool).  FIXME: Make the AR_FLAGS
 # variable obsoleted/removed.
 
-: ${AR_FLAGS=${ARFLAGS-cru}}
+: ${AR_FLAGS=${ARFLAGS-cr}}
 lt_ar_flags="$AR_FLAGS"
 _LT_DECL([], [lt_ar_flags], [0], [Flags to create an archive (by configure)])
 
-- 
2.1.0


--nextPart4584029.ZNY48Cg3c8--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 17 Apr 2015 16:08:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 17 12:08:05 2015
Received: from localhost ([127.0.0.1]:59216 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Yj8oG-0003ZC-WF
	for submit <at> debbugs.gnu.org; Fri, 17 Apr 2015 12:08:05 -0400
Received: from mail.lysator.liu.se ([130.236.254.3]:58789)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <peda@HIDDEN>)
 id 1Yj8oD-0003Yb-WF; Fri, 17 Apr 2015 12:08:03 -0400
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
 by mail.lysator.liu.se (Postfix) with ESMTP id B078140043;
 Fri, 17 Apr 2015 18:07:59 +0200 (CEST)
Received: from [192.168.0.68] (217-210-101-82-no95.business.telia.com
 [217.210.101.82])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.lysator.liu.se (Postfix) with ESMTPSA id 4A62B4003B;
 Fri, 17 Apr 2015 18:07:59 +0200 (CEST)
Message-ID: <55312FDD.50704@HIDDEN>
Date: Fri, 17 Apr 2015 18:07:57 +0200
From: Peter Rosin <peda@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Pavel Raiskup <praiskup@HIDDEN>, Eric Blake <eblake@HIDDEN>
Subject: Re: bug#20082: new warning from ar on rawhide systems
References: <55006845.10402@HIDDEN>
 <55158A98.8080904@HIDDEN>	<1532668.Bmfl2sATKI@HIDDEN>
 <2462821.S22axYa0uW@HIDDEN>
In-Reply-To: <2462821.S22axYa0uW@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 2015-04-17 17:54, Pavel Raiskup wrote:
> [+cc Ralf]
> 
> On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote:
>> On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
>>> Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
>>> 'cru', so that projects that want to silence the warning now can do so
>>> without waiting on automake to catch up?  (Remember, the warning is live
>>> on rawhide systems now, and even if we release a new automake with a
>>> patch to change the default, there are TONS of packages built with older
>>> automake that will still warn until such time as autoreconf is run on
>>> those packages to update them to the newer automake)
>>
>> Agreed here, while trying to look at possible patch, I found that libtool
>> historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
>> http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
>> So fixing automake does not help for libtool-enabled projects, and, in some
>> situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
>> define on per-project basis.
>>
>> FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
>> ARFLAGS from ~2003 (commit a71b3490639831ca).
>>
>> This is probably different issue, but sync is needed..  having two variables
>> doing the same is pain.   What about make libtool respect the ARFLAGS also
>> even though it is younger variable?  Just because ARFLAGS looks more
>> consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
>> AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
>> same for automake?
> 
> Sorry for the delay.  I tried to look at it, but I accidentally found the
> old topic: https://www.mail-archive.com/bug-libtool@HIDDEN/msg01198.html
> .. where Ralf describes that we should be careful of merging ARFLAGS and
> AR_FLAGS variables - but I don't understand it correctly, tbh:
> 
> On Mon, 20 Aug 2007 14:00:21 -0700  Ralf Wildenhues wrote:
>> Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
>> wee bit better.  Except that Automake uses
>>   $(AR) $(ARFLAGS) LIBRARY OBJECTS...
>>
>> and Libtool would like to not have a space after ${ARFLAGS}, if it wants
>> to support the w32 LIB program.
> 
> Because within actual Libtool, if there is $AR_FLAGS used there is always
> something like  '$AR<space>$AR_FLAGS<space>...'.  It means the space _is_
> already there.
> 
> Why would user want to use 'make "ARFLAGS=cru "' (I mean calling something
> like 'ar "cru " ...'), Ralf?  Or anybody?
> 
> I tried to prepare the patch, but thats probably wrong.  It would be nice
> if somebody could comment,

Microsofts archiver (lib.exe) uses a syntax like:

  lib -extract:file.o archive.lib

where -extract: was thought to be the content of $AR_FLAGS.

But since then, I added the ar-lib helper to Automake, which hides
these brain-damaged flags that lib expects.

Cheers,
Peter





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 17 Apr 2015 15:54:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 17 11:54:40 2015
Received: from localhost ([127.0.0.1]:59179 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Yj8bH-0001Wu-8B
	for submit <at> debbugs.gnu.org; Fri, 17 Apr 2015 11:54:39 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59823)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Yj8bE-0001Wb-HG; Fri, 17 Apr 2015 11:54:37 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3HFsXVJ017265
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Fri, 17 Apr 2015 11:54:33 -0400
Received: from nb.usersys.redhat.com (ovpn-200-46.brq.redhat.com
 [10.40.200.46])
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t3HFsUUE025675
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Fri, 17 Apr 2015 11:54:32 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: Eric Blake <eblake@HIDDEN>
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 17 Apr 2015 17:54:30 +0200
Message-ID: <2462821.S22axYa0uW@HIDDEN>
User-Agent: KMail/4.14.6 (Linux/3.19.3-200.fc21.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <1532668.Bmfl2sATKI@HIDDEN>
References: <55006845.10402@HIDDEN> <55158A98.8080904@HIDDEN>
 <1532668.Bmfl2sATKI@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart4469295.pdJgpinANj"
Content-Transfer-Encoding: 7Bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, Ralf.Wildenhues@HIDDEN, 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is a multi-part message in MIME format.

--nextPart4469295.pdJgpinANj
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

[+cc Ralf]

On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote:
> On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
> > Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
> > 'cru', so that projects that want to silence the warning now can do so
> > without waiting on automake to catch up?  (Remember, the warning is live
> > on rawhide systems now, and even if we release a new automake with a
> > patch to change the default, there are TONS of packages built with older
> > automake that will still warn until such time as autoreconf is run on
> > those packages to update them to the newer automake)
> 
> Agreed here, while trying to look at possible patch, I found that libtool
> historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
> http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
> So fixing automake does not help for libtool-enabled projects, and, in some
> situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
> define on per-project basis.
> 
> FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
> ARFLAGS from ~2003 (commit a71b3490639831ca).
> 
> This is probably different issue, but sync is needed..  having two variables
> doing the same is pain.   What about make libtool respect the ARFLAGS also
> even though it is younger variable?  Just because ARFLAGS looks more
> consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
> AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
> same for automake?

Sorry for the delay.  I tried to look at it, but I accidentally found the
old topic: https://www.mail-archive.com/bug-libtool@HIDDEN/msg01198.html
.. where Ralf describes that we should be careful of merging ARFLAGS and
AR_FLAGS variables - but I don't understand it correctly, tbh:

On Mon, 20 Aug 2007 14:00:21 -0700  Ralf Wildenhues wrote:
> Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
> wee bit better.  Except that Automake uses
>   $(AR) $(ARFLAGS) LIBRARY OBJECTS...
> 
> and Libtool would like to not have a space after ${ARFLAGS}, if it wants
> to support the w32 LIB program.

Because within actual Libtool, if there is $AR_FLAGS used there is always
something like  '$AR<space>$AR_FLAGS<space>...'.  It means the space _is_
already there.

Why would user want to use 'make "ARFLAGS=cru "' (I mean calling something
like 'ar "cru " ...'), Ralf?  Or anybody?

I tried to prepare the patch, but thats probably wrong.  It would be nice
if somebody could comment,

Thanks, Pavel

--nextPart4469295.pdJgpinANj
Content-Disposition: attachment; filename="0001-libool.m4-incorporate-ARFLAGS-variable.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="0001-libool.m4-incorporate-ARFLAGS-variable.patch"

From e42bf7080e08a3216fe5c496ffd9e7ec66ecdd04 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@HIDDEN>
Date: Fri, 17 Apr 2015 15:05:42 +0200
Subject: [PATCH 1/2] libool.m4: incorporate ARFLAGS variable

Based on quick observation, Libtool has used AR_FLAGS since ~2000
(commit 8300de4c54e6f04f0d), Automake ARFLAGS from ~2003 (commit
a71b3490639831ca).  Even though ARFLAGS is younger, it sounds like
more consistent naming according to variables like LDFLAGS,
CFLAGS, etc.

For now, take the ARFLAGS as equivalent for AR_FLAGS, don't change
internal code to use ARFLAGS also.  Also, make the value of
ARFLAGS overridable during libtool run-time.
---
 NEWS          |  5 +++++
 m4/libtool.m4 | 17 +++++++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index c5c9023..f9b863b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** New features:
+
+  - libtool script and libtool.m4 now supports ARFLAGS variable name
+    that should in long term replace AR_FLAGS (to be consistent
+    with Automake)
 
 * Noteworthy changes in release 2.4.6 (2015-02-15) [stable]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index a3bc337..26b7530 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1493,9 +1493,22 @@ need_locks=$enable_libtool_lock
 m4_defun([_LT_PROG_AR],
 [AC_CHECK_TOOLS(AR, [ar], false)
 : ${AR=ar}
-: ${AR_FLAGS=cru}
 _LT_DECL([], [AR], [1], [The archiver])
-_LT_DECL([], [AR_FLAGS], [1], [Flags to create an archive])
+
+# Use ARFLAGS variable as AR's operation code to sync the variable naming with
+# Automake.  If both AR_FLAGS and ARFLAGS are specified, AR_FLAGS should have
+# higher priority because thats what people were doing historically (setting
+# ARFLAGS for automake and AR_FLAGS for libtool).  FIXME: Make the AR_FLAGS
+# variable obsoleted/removed.
+
+: ${AR_FLAGS=${ARFLAGS-cru}}
+lt_ar_flags="$AR_FLAGS"
+_LT_DECL([], [lt_ar_flags], [0], [Flags to create an archive (by configure)])
+
+# Make AR_FLAGS overridable by 'make ARFLAGS='.  Don't try to run-time override
+# by AR_FLAGS because that was never working and AR_FLAGS is about to die.
+_LT_DECL([], [AR_FLAGS], [\${ARFLAGS-"\$lt_ar_flags"}],
+         [Flags to create an archive])
 
 AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file],
   [lt_cv_ar_at_file=no
-- 
2.1.0


--nextPart4469295.pdJgpinANj--





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 27 Mar 2015 20:43:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 27 16:43:24 2015
Received: from localhost ([127.0.0.1]:38366 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Ybb6B-0007K5-DY
	for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 16:43:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43532)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>)
 id 1Ybb67-0007Jp-Af; Fri, 27 Mar 2015 16:43:20 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (Postfix) with ESMTPS id 3097D8E3EB;
 Fri, 27 Mar 2015 20:43:17 +0000 (UTC)
Received: from nb.usersys.redhat.com (ovpn-200-18.brq.redhat.com
 [10.40.200.18])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t2RKhEXR027736
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Fri, 27 Mar 2015 16:43:16 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: Eric Blake <eblake@HIDDEN>
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 27 Mar 2015 21:43:14 +0100
Message-ID: <1532668.Bmfl2sATKI@HIDDEN>
User-Agent: KMail/4.14.4 (Linux/3.19.1-201.fc21.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <55158A98.8080904@HIDDEN>
References: <55006845.10402@HIDDEN>
 <2175381.7nxLX7YIP6@HIDDEN> <55158A98.8080904@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[+cc back libtool bug; as fixing automake does not seem to be enough]

On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
> On 03/27/2015 09:48 AM, Pavel Raiskup wrote:
> 
> > So probably the worst slowdown would be an 'ar' task to update archive
> > consisting of a big amount of small files when only one has changed.
> > 
> > FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
> > uses 'cr' only.
> > 
> >> And of course there's the question of how easy is it to detect that ar
> >> is new enough to understand the 'D'/'U' dichotomy?
> > 
> > Not sure.  Probably ./configure check like '--version works' && 'GNU in
> > --version' && 'ar crD' could be enough..
> 
> Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
> 'cru', so that projects that want to silence the warning now can do so
> without waiting on automake to catch up?  (Remember, the warning is live
> on rawhide systems now, and even if we release a new automake with a
> patch to change the default, there are TONS of packages built with older
> automake that will still warn until such time as autoreconf is run on
> those packages to update them to the newer automake)

Agreed here, while trying to look at possible patch, I found that libtool
historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
So fixing automake does not help for libtool-enabled projects, and, in some
situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
define on per-project basis.

FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
ARFLAGS from ~2003 (commit a71b3490639831ca).

This is probably different issue, but sync is needed..  having two variables
doing the same is pain.   What about make libtool respect the ARFLAGS also
even though it is younger variable?  Just because ARFLAGS looks more
consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
same for automake?

> > However, having best-effort determinism in Automake does not guarantee
> > determinism of final result..  Is it worth the trouble?  I could imagine
> > some general './configure --enable-deterministic-build', but then I would
> > expect the configure to fail if the 'D' option is not available..
> > 
> > Having used 'cru' with optional 'cruU' could have at least a small benefit
> > that the default behavior would behave consistently at least on boxes
> > running GNU ar..  which is not the actual state.
> 
> So you are arguing that 'crD' is smarter than 'cruU' if we bother to detect
> new enough binutils, but that 'cr' is just about as effective and then
> we don't have to worry about the detection at all.

I _personally_ feel it this way.

If we are not able to guarantee deterministic $AR _everywhere_ it looks
fighting non-determinism via additional configure time checks (in default
case) is worthless; we can let the decision up to binutils or user.

> And if I understand correctly, the warning occurs if we use just 'cru' but
> the binutils defaulted to 'D' (rather amusing, that 'cruD' is the spelling
> that warns).

Yes, 'cruD' warns, nice!

> Next step - how to patch automake.  I'm not familiar enough with the
> internals to quickly find the location to patch, if someone else is able
> to do it quickly.

I was about to propose the patch, but I will need a bit more time to
re-think the libtool consistency issue, to ideally fix this together.
If there is no other problem .. or somebody faster to do the proposal.

Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 27 Mar 2015 16:51:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 27 12:51:40 2015
Received: from localhost ([127.0.0.1]:38296 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YbXTv-0001pz-QA
	for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 12:51:40 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60774)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>) id 1YbXTu-0001po-IU
 for 20082 <at> debbugs.gnu.org; Fri, 27 Mar 2015 12:51:39 -0400
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
 (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
 by mx1.redhat.com (Postfix) with ESMTPS id BA2ACB0421
 for <20082 <at> debbugs.gnu.org>; Fri, 27 Mar 2015 16:51:37 +0000 (UTC)
Received: from [10.3.113.15] ([10.3.113.15])
 by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t2RGpaYp030903; Fri, 27 Mar 2015 12:51:37 -0400
Message-ID: <55158A98.8080904@HIDDEN>
Date: Fri, 27 Mar 2015 10:51:36 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Pavel Raiskup <praiskup@HIDDEN>, 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
References: <55006845.10402@HIDDEN>
 <2175381.7nxLX7YIP6@HIDDEN>
In-Reply-To: <2175381.7nxLX7YIP6@HIDDEN>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="vSGetOSHAfD53CugUlrahi4RBKnExsT3U"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vSGetOSHAfD53CugUlrahi4RBKnExsT3U
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 03/27/2015 09:48 AM, Pavel Raiskup wrote:

> So probably the worst slowdown would be an 'ar' task to update archive
> consisting of a big amount of small files when only one has changed.
>=20
> FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cm=
ake
> uses 'cr' only.
>=20
>> And of course there's the question of how easy is it to detect that ar=

>> is new enough to understand the 'D'/'U' dichotomy?
>=20
> Not sure.  Probably ./configure check like '--version works' && 'GNU in=

> --version' && 'ar crD' could be enough..

Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
'cru', so that projects that want to silence the warning now can do so
without waiting on automake to catch up?  (Remember, the warning is live
on rawhide systems now, and even if we release a new automake with a
patch to change the default, there are TONS of packages built with older
automake that will still warn until such time as autoreconf is run on
those packages to update them to the newer automake)

>=20
> However, having best-effort determinism in Automake does not guarantee
> determinism of final result..  Is it worth the trouble?  I could imagin=
e
> some general './configure --enable-deterministic-build', but then I wou=
ld
> expect the configure to fail if the 'D' option is not available..
>=20
> Having used 'cru' with optional 'cruU' could have at least a small bene=
fit
> that the default behavior would behave consistently at least on boxes
> running GNU ar..  which is not the actual state.

So you are arguing that 'crD' is smarter than 'cruU' if we bother to
detect new enough binutils, but that 'cr' is just about as effective and
then we don't have to worry about the detection at all.  And if I
understand correctly, the warning occurs if we use just 'cru' but the
binutils defaulted to 'D' (rather amusing, that 'cruD' is the spelling
that warns).

Next step - how to patch automake.  I'm not familiar enough with the
internals to quickly find the location to patch, if someone else is able
to do it quickly.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--vSGetOSHAfD53CugUlrahi4RBKnExsT3U
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJVFYqYAAoJEKeha0olJ0NqQd4H/iIaV2pioIQ3GqFSkNGmBYi7
XBCxFq3fG72ZvwA8cl/McJ+HYBYWnmwcXr2sl8HTkL+TYlj9C8npm8LLg/a8zgkH
ZWli2OLc9omm00IoSg883EDwOocV1ECf2KNeM8WzPaexOSkG4Btn3bT15xZxT+rj
exEET1SqxSxL0dyXw31zmjfQ5VPMtdwe2fAkO8AtLWFv0wh85OEw3tBOWWEqefux
XS5dcBplR5U4PneH9y4Af9ufvwyDjsKGlWYsLFHIxCGZL5kbaScREtKHiwbMZdDw
BspIvXWe/VfeiOxi1q5tZQF7kA+edWmsk4iKx81OHNvhoVLO0drR2v0xiwZQImI=
=ZZPh
-----END PGP SIGNATURE-----

--vSGetOSHAfD53CugUlrahi4RBKnExsT3U--




Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at 20082 <at> debbugs.gnu.org:


Received: (at 20082) by debbugs.gnu.org; 27 Mar 2015 15:48:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 27 11:48:43 2015
Received: from localhost ([127.0.0.1]:38272 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YbWV0-0000LP-FU
	for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40439)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>) id 1YbWUw-0000L8-0l
 for 20082 <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:39 -0400
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
 (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2RFmZUg015057
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Fri, 27 Mar 2015 11:48:35 -0400
Received: from nb.usersys.redhat.com (unused-4-182.brq.redhat.com
 [10.34.4.182])
 by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t2RFmYTO000671
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Fri, 27 Mar 2015 11:48:35 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-automake@HIDDEN
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 27 Mar 2015 16:48:33 +0100
Message-ID: <2175381.7nxLX7YIP6@HIDDEN>
User-Agent: KMail/4.14.4 (Linux/3.19.1-201.fc21.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <55006845.10402@HIDDEN>
References: <55006845.10402@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 20082
Cc: Eric Blake <eblake@HIDDEN>, 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

On Wednesday 11 of March 2015 10:07:33 Eric Blake wrote:
> When compiling libvirt (and probably other packages) on Fedora rawhide
> systems, I'm seeing a new warning message on every link line.
>
> # rpm -q libtool gcc binutils
> libtool-2.4.6-1.fc23.x86_64
> gcc-5.0.0-0.16.fc23.x86_64
> binutils-2.25-6.fc23.x86_64
>
> For an example of the warning during a 'make V=1':
>
> > libtool: link: rm -fr  .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la
> > libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o
> > ar: `u' modifier ignored since `D' is the default (see `U')
> > libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a
>
> Reading 'man ar', it looks like a relatively new binutils invention, one
> that Fedora chose to flip on by default, but also one that might be
> worth using even when ar is built with 'U' rather than 'D' as the default:
>
> >        D   Operate in deterministic mode.  When adding files and the archive
> >            index use zero for UIDs, GIDs, timestamps, and use consistent file
> >            modes for all files.  When this option is used, if ar is used with
> >            identical options and identical input files, multiple runs will
> >            create identical output files regardless of the input files'
> >            owners, groups, file modes, or modification times.
> >
> >            If binutils was configured with --enable-deterministic-archives,
> >            then this mode is on by default.  It can be disabled with the U
> >            modifier, below.
>
> Is it worth teaching automake to change ARFLAGS to be 'crD' instead of
> 'cru' when it is detected that ar is new enough to support deterministic
> libraries, in part to shut up the warning message being printed on every
> single libtool link line?  (Note that I would explicitly include 'D',
> because even though Fedora chose to make 'D' the default, other distros
> may choose to make 'U' the default).  Or conversely, do we want ARFLAGS
> to be 'cruU', to force non-deterministic mode, since any speedups made
> possible by timestamp comparison ('u') are only possible in
> non-deterministic mode?  Does the use of 'u' buy us much measurable time
> when repeatedly and incrementally linking large libraries, where the new
> 'D' mode is forced to link everything instead of just the new inputs?

From GNU ar code I assume that having the 'u' might save some file opening
and closing, because only files with newer timestamp are opened to be
copyied into new archive with 'u'.  Files with mtime lower than the
corresponding archive member are copyied directly from (already opened)
old archive.

If at least one member was updated on the disk before calling 'ar cru',
_new_ archive is created (no in place update of archive).  When no file
was changed, GNU ar does not touch existing archive.  In Makefile
(precisely defined dependencies) this is not useful optimization however..

So probably the worst slowdown would be an 'ar' task to update archive
consisting of a big amount of small files when only one has changed.

FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
uses 'cr' only.

> And of course there's the question of how easy is it to detect that ar
> is new enough to understand the 'D'/'U' dichotomy?

Not sure.  Probably ./configure check like '--version works' && 'GNU in
--version' && 'ar crD' could be enough..

However, having best-effort determinism in Automake does not guarantee
determinism of final result..  Is it worth the trouble?  I could imagine
some general './configure --enable-deterministic-build', but then I would
expect the configure to fail if the 'D' option is not available..

Having used 'cru' with optional 'cruU' could have at least a small benefit
that the default behavior would behave consistently at least on boxes
running GNU ar..  which is not the actual state.

IMO, removing the 'u' optimization for everybody is the easiest thing to
do.  Its suboptimal because 'u' is probably portable enough it has worked
for automake for 20+ year.. and we would remove it just to silence warning
on some platforms .. but ..

> I've already asked on libtool, and they suggested it is an automake issue.

The link to make it complete:
http://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html

Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 27 Mar 2015 15:48:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 27 11:48:55 2015
Received: from localhost ([127.0.0.1]:38275 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YbWVC-0000Lp-Ek
	for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:54 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53621)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <praiskup@HIDDEN>) id 1YbWVA-0000Lc-6W
 for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1YbWV3-0002Tg-Dp
 for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:46 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:44734)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1YbWV3-0002Tc-Ba
 for submit <at> debbugs.gnu.org; Fri, 27 Mar 2015 11:48:45 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55317)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1YbWV1-00005E-Lw
 for bug-automake@HIDDEN; Fri, 27 Mar 2015 11:48:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1YbWUy-0002SI-Dl
 for bug-automake@HIDDEN; Fri, 27 Mar 2015 11:48:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39275)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <praiskup@HIDDEN>) id 1YbWUy-0002S8-6L
 for bug-automake@HIDDEN; Fri, 27 Mar 2015 11:48:40 -0400
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
 (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2RFmZUg015057
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Fri, 27 Mar 2015 11:48:35 -0400
Received: from nb.usersys.redhat.com (unused-4-182.brq.redhat.com
 [10.34.4.182])
 by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t2RFmYTO000671
 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
 Fri, 27 Mar 2015 11:48:35 -0400
From: Pavel Raiskup <praiskup@HIDDEN>
To: bug-automake@HIDDEN
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 27 Mar 2015 16:48:33 +0100
Message-ID: <2175381.7nxLX7YIP6@HIDDEN>
User-Agent: KMail/4.14.4 (Linux/3.19.1-201.fc21.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <55006845.10402@HIDDEN>
References: <55006845.10402@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
Cc: Eric Blake <eblake@HIDDEN>, 20082 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

On Wednesday 11 of March 2015 10:07:33 Eric Blake wrote:
> When compiling libvirt (and probably other packages) on Fedora rawhide
> systems, I'm seeing a new warning message on every link line.
>
> # rpm -q libtool gcc binutils
> libtool-2.4.6-1.fc23.x86_64
> gcc-5.0.0-0.16.fc23.x86_64
> binutils-2.25-6.fc23.x86_64
>
> For an example of the warning during a 'make V=1':
>
> > libtool: link: rm -fr  .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la
> > libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o
> > ar: `u' modifier ignored since `D' is the default (see `U')
> > libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a
>
> Reading 'man ar', it looks like a relatively new binutils invention, one
> that Fedora chose to flip on by default, but also one that might be
> worth using even when ar is built with 'U' rather than 'D' as the default:
>
> >        D   Operate in deterministic mode.  When adding files and the archive
> >            index use zero for UIDs, GIDs, timestamps, and use consistent file
> >            modes for all files.  When this option is used, if ar is used with
> >            identical options and identical input files, multiple runs will
> >            create identical output files regardless of the input files'
> >            owners, groups, file modes, or modification times.
> >
> >            If binutils was configured with --enable-deterministic-archives,
> >            then this mode is on by default.  It can be disabled with the U
> >            modifier, below.
>
> Is it worth teaching automake to change ARFLAGS to be 'crD' instead of
> 'cru' when it is detected that ar is new enough to support deterministic
> libraries, in part to shut up the warning message being printed on every
> single libtool link line?  (Note that I would explicitly include 'D',
> because even though Fedora chose to make 'D' the default, other distros
> may choose to make 'U' the default).  Or conversely, do we want ARFLAGS
> to be 'cruU', to force non-deterministic mode, since any speedups made
> possible by timestamp comparison ('u') are only possible in
> non-deterministic mode?  Does the use of 'u' buy us much measurable time
> when repeatedly and incrementally linking large libraries, where the new
> 'D' mode is forced to link everything instead of just the new inputs?

From GNU ar code I assume that having the 'u' might save some file opening
and closing, because only files with newer timestamp are opened to be
copyied into new archive with 'u'.  Files with mtime lower than the
corresponding archive member are copyied directly from (already opened)
old archive.

If at least one member was updated on the disk before calling 'ar cru',
_new_ archive is created (no in place update of archive).  When no file
was changed, GNU ar does not touch existing archive.  In Makefile
(precisely defined dependencies) this is not useful optimization however..

So probably the worst slowdown would be an 'ar' task to update archive
consisting of a big amount of small files when only one has changed.

FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
uses 'cr' only.

> And of course there's the question of how easy is it to detect that ar
> is new enough to understand the 'D'/'U' dichotomy?

Not sure.  Probably ./configure check like '--version works' && 'GNU in
--version' && 'ar crD' could be enough..

However, having best-effort determinism in Automake does not guarantee
determinism of final result..  Is it worth the trouble?  I could imagine
some general './configure --enable-deterministic-build', but then I would
expect the configure to fail if the 'D' option is not available..

Having used 'cru' with optional 'cruU' could have at least a small benefit
that the default behavior would behave consistently at least on boxes
running GNU ar..  which is not the actual state.

IMO, removing the 'u' optimization for everybody is the easiest thing to
do.  Its suboptimal because 'u' is probably portable enough it has worked
for automake for 20+ year.. and we would remove it just to silence warning
on some platforms .. but ..

> I've already asked on libtool, and they suggested it is an automake issue.

The link to make it complete:
http://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html

Pavel





Information forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 11 Mar 2015 16:07:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 12:07:49 2015
Received: from localhost ([127.0.0.1]:42971 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YVjAj-0002fH-BM
	for submit <at> debbugs.gnu.org; Wed, 11 Mar 2015 12:07:49 -0400
Received: from eggs.gnu.org ([208.118.235.92]:36342)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>) id 1YVjAg-0002f4-Aj
 for submit <at> debbugs.gnu.org; Wed, 11 Mar 2015 12:07:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1YVjAZ-0006Ax-Tj
 for submit <at> debbugs.gnu.org; Wed, 11 Mar 2015 12:07:40 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:34213)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1YVjAZ-0006At-Qr
 for submit <at> debbugs.gnu.org; Wed, 11 Mar 2015 12:07:39 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38044)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1YVjAY-0002UO-GB
 for bug-automake@HIDDEN; Wed, 11 Mar 2015 12:07:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1YVjAV-00069m-Pb
 for bug-automake@HIDDEN; Wed, 11 Mar 2015 12:07:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:41660)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1YVjAV-00069Z-He
 for bug-automake@HIDDEN; Wed, 11 Mar 2015 12:07:35 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BG7YHf000880
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL)
 for <bug-automake@HIDDEN>; Wed, 11 Mar 2015 12:07:34 -0400
Received: from [10.3.113.62] (ovpn-113-62.phx2.redhat.com [10.3.113.62])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t2BG7XSh024920
 for <bug-automake@HIDDEN>; Wed, 11 Mar 2015 12:07:34 -0400
Message-ID: <55006845.10402@HIDDEN>
Date: Wed, 11 Mar 2015 10:07:33 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: bug-automake@HIDDEN
Subject: new warning from ar on rawhide systems
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="fPmjXWJfWBW2tlskJWdPruu6TujLM6MEv"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fPmjXWJfWBW2tlskJWdPruu6TujLM6MEv
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

When compiling libvirt (and probably other packages) on Fedora rawhide
systems, I'm seeing a new warning message on every link line.

# rpm -q libtool gcc binutils
libtool-2.4.6-1.fc23.x86_64
gcc-5.0.0-0.16.fc23.x86_64
binutils-2.25-6.fc23.x86_64

For an example of the warning during a 'make V=3D1':

> libtool: link: rm -fr  .libs/libvirt_driver_qemu_impl.a .libs/libvirt_d=
river_qemu_impl.la
> libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvi=
rt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_l=
a-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command=
=2Eo qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libv=
irt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl=
_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o =
qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_dri=
ver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qe=
mu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu=
/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt=
_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_i=
mpl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interfac=
e.o=20
> ar: `u' modifier ignored since `D' is the default (see `U')
> libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a

Reading 'man ar', it looks like a relatively new binutils invention, one
that Fedora chose to flip on by default, but also one that might be
worth using even when ar is built with 'U' rather than 'D' as the default=
:

>        D   Operate in deterministic mode.  When adding files and the ar=
chive
>            index use zero for UIDs, GIDs, timestamps, and use consisten=
t file
>            modes for all files.  When this option is used, if ar is use=
d with
>            identical options and identical input files, multiple runs w=
ill
>            create identical output files regardless of the input files'=

>            owners, groups, file modes, or modification times.
>=20
>            If binutils was configured with --enable-deterministic-archi=
ves,
>            then this mode is on by default.  It can be disabled with th=
e U
>            modifier, below.

Is it worth teaching automake to change ARFLAGS to be 'crD' instead of
'cru' when it is detected that ar is new enough to support deterministic
libraries, in part to shut up the warning message being printed on every
single libtool link line?  (Note that I would explicitly include 'D',
because even though Fedora chose to make 'D' the default, other distros
may choose to make 'U' the default).  Or conversely, do we want ARFLAGS
to be 'cruU', to force non-deterministic mode, since any speedups made
possible by timestamp comparison ('u') are only possible in
non-deterministic mode?  Does the use of 'u' buy us much measurable time
when repeatedly and incrementally linking large libraries, where the new
'D' mode is forced to link everything instead of just the new inputs?
And of course there's the question of how easy is it to detect that ar
is new enough to understand the 'D'/'U' dichotomy?

I've already asked on libtool, and they suggested it is an automake issue=
=2E

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org




--fPmjXWJfWBW2tlskJWdPruu6TujLM6MEv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJVAGhFAAoJEKeha0olJ0Nqn/YIAJMX0SClBx/sicKz27zEnLEe
X58hl8KOv3xe+8F4yyJtxoUWmVrahD+4SojfcK1aFSDbCvDTweg3Khao5Edj9VHJ
XFssx4uCNZEoDnS8cpTuX/W+MGlXoriGblNUqjxL7AaVIAfsZkbVMpwrwzNTerub
kWAmOv+ihYTRFMXBx/nh3bxmJCIVgUwykbF6+bLy1KnDAJJnAg7sdM+kMwJPoLc/
45Tqt0rhOmQq11svH4OfphhywOsIxA1qIrNAQEMlOkNIIMt3nZ4df0pBlAhspyYV
dCTR8r3AVMy5T9hX+CoLEjcvN+QgDbNGMFuqrDxknl9z02tx9YfJ6BljSkt4d8Q=
=DAc7
-----END PGP SIGNATURE-----

--fPmjXWJfWBW2tlskJWdPruu6TujLM6MEv--




Acknowledgement sent to Eric Blake <eblake@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-automake@HIDDEN. Full text available.
Report forwarded to bug-automake@HIDDEN:
bug#20082; Package automake. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 29 Sep 2015 09:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.