Re: [PATCH] add new AC_PROG_AR helper

[Zack Weinberg]

On Tue, Jan 25, 2022, at 12:58 AM, Mike Frysinger wrote:
> On 24 Jan 2022 09:35, Zack Weinberg wrote:
>> Sorry about that, I thought you would merge it yourself (do you not have
>> commit access for autoconf?)  It's merged now.  I had to add a change to
>> tests/local.at to allow AR to be set.
>
> ah, i see, that can be confusing.  i don't have access to autoconf.  am i
> supposed to ? :)

I don't see any reason why you shouldn't, so I went ahead and added you in 
Savannah.

>> Did you ever get around to checking whether there was code in automake and/or
>> libtool that is now redundant to this macro?
>
> i posted some findings:
> https://lists.gnu.org/archive/html/autoconf-patches/2021-02/msg00011.html
>
> but i was going to wait for it to be canonical before proposing any patches.

Right, I remember seeing that go by now.  (Has it _really_ been almost a year?!)

It might make sense for Autoconf's AC_PROG_AR to check whether the 'ar' it 
finds is at least basically command-line compatible with traditional Unix 'ar', 
and maybe also check whether it's going to spew "`u' modifier ignored since `D' 
is the default (see `U')" messages like current binutils ar tends to (see e.g. 
https://bugzilla.redhat.com/show_bug.cgi?id=1155273 -- as far as I can tell the 
message is harmless, but if we can reduce the number of junk bug reports that 
random autotools-using projects have to field, that's a Good Thing).  I agree 
that providing glue to support "lib", "link", and other such tools (that also 
create static libraries, but that aren't command line compatible) is out of 
scope for AC_PROG_AR.

zw