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@gnu.org/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
