bug#20082: new warning from ar on rawhide systems

[Pavel Raiskup]

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