bug#19967: bug#20082: new warning from ar on rawhide systems

[Peter Rosin]

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/address@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