Subject: Re: bug#20082: new warning from ar on rawhide systems

From: Pavel Raiskup <[email-masked]>
Date: Fri, 17 Apr 2015 17:54:30 +0200

[+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/[email-masked]/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
>From e42bf7080e08a3216fe5c496ffd9e7ec66ecdd04 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <[email-masked]>
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