[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20082: new warning from ar on rawhide systems
From: |
Pavel Raiskup |
Subject: |
bug#20082: new warning from ar on rawhide systems |
Date: |
Fri, 17 Apr 2015 17:54:30 +0200 |
User-agent: |
KMail/4.14.6 (Linux/3.19.3-200.fc21.x86_64; KDE/4.14.6; x86_64; ; ) |
[+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,
Thanks, Pavel
0001-libool.m4-incorporate-ARFLAGS-variable.patch
Description: Text Data
- bug#20082: new warning from ar on rawhide systems,
Pavel Raiskup <=