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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19967 in the body.
You can then email your comments to 19967 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: "libvir-list <at> redhat.com" <libvir-list <at> redhat.com>
Subject: new warning from ar on rawhide systems
Date: Fri, 27 Feb 2015 16:38:46 -0700

[Message part 1 (text/plain, inline)]

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 libtool 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?

Is this something I should redirect to automake instead of libtool?

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

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Eric Blake <eblake <at> redhat.com>
Cc: "libvir-list <at> redhat.com" <libvir-list <at> redhat.com>, 19967 <at> debbugs.gnu.org,
 bug-libtool <at> gnu.org
Subject: Re: bug#19967: new warning from ar on rawhide systems
Date: Fri, 27 Feb 2015 19:31:32 -0600 (CST)

On Fri, 27 Feb 2015, Eric Blake wrote:
>
> Is it worth teaching libtool 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?

It seems that -D mode only works if the archive is created from 
scratch, or the argument file list supplied is the same (including 
order) each time.  This does not seem to be compatible with the 
options -ru which update the archive only if the provided file is 
newer, and may also be used in an incremental mode of operation (e.g. 
just one file is re-compiled).

Regardless, 'cru' is portable other toolchains/systems whereas -D 
seems to be limited to binutils.

> Is this something I should redirect to automake instead of libtool?

Perhaps so since it seems that Automake is in the driver's seat here.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #14 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 27 Mar 2015 21:43:14 +0100

[+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

Message #17 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 19967 <at> debbugs.gnu.org, Ralf.Wildenhues <at> gmx.de, 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 17 Apr 2015 17:54:30 +0200

[Message part 1 (text/plain, inline)]

[+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 <at> 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,

Thanks, Pavel

[0001-libool.m4-incorporate-ARFLAGS-variable.patch (text/x-patch, attachment)]

Message #20 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Pavel Raiskup <praiskup <at> redhat.com>, Eric Blake <eblake <at> redhat.com>
Cc: 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 17 Apr 2015 18:07:57 +0200

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 <at> 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

Message #23 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 19967 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Sat, 18 Apr 2015 11:50:31 +0200

[Message part 1 (text/plain, inline)]

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

[0001-libool.m4-incorporate-ARFLAGS-variable.patch (text/x-patch, attachment)]

[0002-ARFLAGS-use-cr-instead-of-cru-by-default.patch (text/x-patch, attachment)]

Message #26 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-automake <at> gnu.org
Cc: Peter Rosin <peda <at> lysator.liu.se>, 20082 <at> debbugs.gnu.org,
 Eric Blake <eblake <at> redhat.com>, Automake Patches <automake-patches <at> gnu.org>,
 19967 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Tue, 02 Jun 2015 16:22:50 +0200

[Message part 1 (text/plain, inline)]

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

[0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch (text/x-patch, attachment)]

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: Peter Rosin <peda <at> lysator.liu.se>, 20082 <at> debbugs.gnu.org,
 Eric Blake <eblake <at> redhat.com>, 19967 <at> debbugs.gnu.org
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Wed, 17 Jun 2015 09:22:31 +0200

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

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: bug-gnulib <at> gnu.org, 19967 <at> debbugs.gnu.org, 20082 <at> debbugs.gnu.org,
 eblake <at> redhat.com, peda <at> lysator.liu.se
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Thu, 25 Jun 2015 16:50:12 +0200

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

Message #41 received at 19967 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: 19967 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org, eblake <at> redhat.com,
 20082 <at> debbugs.gnu.org, peda <at> lysator.liu.se
Subject: [gnulib PATCH]: new warning from ar on rawhide systems
Date: Wed, 01 Jul 2015 10:00:52 +0200

[Message part 1 (text/plain, inline)]

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

[0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch (text/x-patch, attachment)]

[0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch (text/x-patch, attachment)]

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org, 20082 <at> debbugs.gnu.org
Cc: 19967 <at> debbugs.gnu.org, control <at> debbugs.gnu.org, eblake <at> redhat.com,
 peda <at> lysator.liu.se
Subject: Re: bug#19967: bug#20082: new warning from ar on rawhide systems
Date: Tue, 29 Sep 2015 10:56:11 +0200

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

Previous Next

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