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