GNU bug report logs - #20082
default ARFLAGS=cru causes warnings when binutils is configured with --enable-deterministic-archives

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 20082 in the body.
You can then email your comments to 20082 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-automake <at> gnu.org
Subject: new warning from ar on rawhide systems
Date: Wed, 11 Mar 2015 10:07:33 -0600

[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 automake 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?

I've already asked on libtool, and they suggested it is an automake issue.

-- 
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 submit <at> debbugs.gnu.org (full text, mbox):

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

On Wednesday 11 of March 2015 10:07:33 Eric Blake wrote:
> 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 automake 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?

From GNU ar code I assume that having the 'u' might save some file opening
and closing, because only files with newer timestamp are opened to be
copyied into new archive with 'u'.  Files with mtime lower than the
corresponding archive member are copyied directly from (already opened)
old archive.

If at least one member was updated on the disk before calling 'ar cru',
_new_ archive is created (no in place update of archive).  When no file
was changed, GNU ar does not touch existing archive.  In Makefile
(precisely defined dependencies) this is not useful optimization however..

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

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.

IMO, removing the 'u' optimization for everybody is the easiest thing to
do.  Its suboptimal because 'u' is probably portable enough it has worked
for automake for 20+ year.. and we would remove it just to silence warning
on some platforms .. but ..

> I've already asked on libtool, and they suggested it is an automake issue.

The link to make it complete:
http://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html

Pavel

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

From: Eric Blake <eblake <at> redhat.com>
To: Pavel Raiskup <praiskup <at> redhat.com>, 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Fri, 27 Mar 2015 10:51:36 -0600

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

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)

> 
> 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.  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).

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.

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

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

Message #17 received at 20082 <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 #20 received at 20082 <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 #23 received at 20082 <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 #26 received at 20082 <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 #29 received at 20082 <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 #35 received at 20082 <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 #38 received at 20082 <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 submit <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 #47 received at 20082 <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

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

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-automake <at> gnu.org
Cc: peda <at> lysator.liu.se, eblake <at> redhat.com, automake-patches <at> gnu.org,
 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Wed, 09 Mar 2016 07:40:49 +0100

On Tuesday 02 of June 2015 16:22:50 Pavel Raiskup wrote:
> 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.

Has anyone looked at this patch so far?  Reviews are appreciated.  As a
downstream maintainer I keep getting questions when this is going to be
fixed.

Thanks, Pavel

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

From: Ralph Corderoy <ralph <at> inputplus.co.uk>
To: 20082 <at> debbugs.gnu.org
Cc: Pavel Raiskup <praiskup <at> redhat.com>, bug-automake <at> gnu.org,
 eblake <at> redhat.com, peda <at> lysator.liu.se
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Mon, 24 Oct 2016 12:02:27 +0100

> Has anyone looked at this patch so far?  Reviews are appreciated.  As
> a downstream maintainer I keep getting questions when this is going to
> be fixed.

Also a problem with automake 1.15-2 on Arch Linux.
Annoying if one's attempting to get "silent" builds that produce no
output if all's well.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

From: Karl Berry <karl <at> freefriends.org>
To: praiskup <at> redhat.com
Cc: 20082 <at> debbugs.gnu.org
Subject: Re: bug#20082: new warning from ar on rawhide systems
Date: Tue, 21 Nov 2023 09:48:06 -0700

    > And the patch against Automake attached now, sorry for the delay.
    https://lists.gnu.org/archive/html/automake-patches/2016-03/msg00000.html

In the better-late-than-never department: after eight years, I've
finally applied this patch to make Automake's default ARFLAGS be cru
instead of cr. (Modulo a few minor wording tweaks.)

Thanks for the patch and the careful explanations. (And thanks to Bogdan
for unearthing this one in the archives.) --best, karl.

-----
From: Pavel Raiskup <praiskup <at> redhat.com>
Date: Tue, 21 Nov 2023 08:30:00 -0800
Subject: [PATCH] automake: make the ARFLAGS default 'cr' instead of 'cru'.

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silence such warnings.

Fixes bug#20082.  Reported by Eric Blake.

* bin/automake.in (handle_libraries): Use 'ARFLAGS=cr' by default.
* doc/automake.texi (Building a library): Mention the changed
ARFLAGS default.
(@c LocalWords): Replace 'cru' with 'cr'.
* m4/ar-lib.m4 (AM_PROG_AR): Cut out 'cru' string into separate
ARFLAGS variable with new default 'cr'.
* NEWS: Document.
---
 NEWS              | 5 ++++-
 bin/automake.in   | 2 +-
 doc/automake.texi | 4 ++--
 m4/ar-lib.m4      | 3 ++-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index d9c8640ff..2a58785f3 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,9 @@ New in 1.17:
   - AM_PATH_PYTHON will also search for Python versions 3.10 - 3.15.  It has
     previously searched for 3.0 - 3.9. (bug#53530)
 
+  - The default value of $ARFLAGS is now "cr" instead of "cru", to
+    support deterministic builds. (bug#20082)
+
   - RANLIB may be overridden on a per-target basis.
 
   - AM_TEXI2FLAGS may be defined to pass extra flags to TEXI2DVI & TEXI2PDF.
@@ -69,7 +72,7 @@ New in 1.17:
   - Pass any options given to AM_PROG_LEX on to AC_PROG_LEX.
     (bug#65600 and bug#65730)
 
-* Obsolescent features:
+* Obsolescence:
 
   - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
     released in 2000, is currently the minimum required version.
diff --git a/bin/automake.in b/bin/automake.in
index edc0488b8..c0ffc1986 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2674,7 +2674,7 @@ sub handle_libraries ()
     }
 
   define_variable ('AR', 'ar', INTERNAL);
-  define_variable ('ARFLAGS', 'cru', INTERNAL);
+  define_variable ('ARFLAGS', 'cr', INTERNAL);
   define_verbose_tagvar ('AR');
 
   foreach my $pair (@liblist)
diff --git a/doc/automake.texi b/doc/automake.texi
index 635bdd28c..af8dd836f 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5181,7 +5181,7 @@ library and the list of objects, and finally by calling
 @code{RANLIB} (Automake will complain otherwise).  You should also
 call @code{AM_PROG_AR} to define @code{AR}, in order to support unusual
 archivers such as Microsoft lib.  @code{ARFLAGS} will default to
-@code{cru}; you can override this variable by setting it in your
+@code{cr}; you can override this variable by setting it in your
 @file{Makefile.am} or by @code{AC_SUBST}ing it from your
 @file{configure.ac}.  You can override the @code{AR} variable by
 defining a per-library @code{maude_AR} variable (@pxref{Program and
@@ -13625,7 +13625,7 @@ attach the @file{test-suite.log} file.
 @c  LocalWords:  Miller's installable includedir inc pkgdata EXEEXT libexec bsd
 @c  LocalWords:  pkglib libexecdir prog libcpio cpio's dlopen dlpreopen linux
 @c  LocalWords:  subsubsection OBJEXT esac lib LTLIBRARIES liblob LIBADD AR ar
-@c  LocalWords:  ARFLAGS cru ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
+@c  LocalWords:  ARFLAGS cr ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
 @c  LocalWords:  libmaude CCLD CXXFLAGS FFLAGS LFLAGS OBJCFLAGS RFLAGS DEFS cc
 @c  LocalWords:  OBJCXXFLAGS
 @c  LocalWords:  SHORTNAME vtable srcdir nostdinc basename yxx cxx ll lxx gdb
diff --git a/m4/ar-lib.m4 b/m4/ar-lib.m4
index f55b65019..e655b26f4 100644
--- a/m4/ar-lib.m4
+++ b/m4/ar-lib.m4
@@ -18,12 +18,13 @@ AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([ar-lib])dnl
 AC_CHECK_TOOLS([AR], [ar lib "link -lib"], [false])
 : ${AR=ar}
+: ${ARFLAGS=cr}
 
 AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface],
   [AC_LANG_PUSH([C])
    am_cv_ar_interface=ar
    AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int some_variable = 0;]])],
-     [am_ar_try='$AR cru libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+     [am_ar_try='$AR $ARFLAGS libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
       AC_TRY_EVAL([am_ar_try])
       if test "$ac_status" -eq 0; then
         am_cv_ar_interface=ar
-- 
2.39.3


compile finished at Tue Nov 21 08:47:03 2023

Previous Next

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