Karl Berry <k...@freefriends.org> writes: > Hi Sam,
Hi Karl, > > but how does this look in principle? > > -AC_CHECK_TOOLS([AR], [ar lib "link -lib"], [false]) > +AC_CHECK_TOOLS([AR], [gcc-ar ar lib "link -lib"], [false]) > > Seems about as simple a change as it could be. Assuming that gcc-ar > behaves like normal ar in normal situations (no plugins or LTO > involved), I don't see a problem with it. It even seems safe enough to > me to make the next release without another pretest. Wdyt? > > My only comment on the patch is that I think this searching for gcc-ar > should be mentioned in the documentation for AM_PROG_AR. (I can do that.) > > I'm still testing this and going to play with it some more in the wild, > > Do you want me to install the patch? A few people run automake from the > dev sources so it would get some minor additional testing that way. Thanks for the prompt and helpful as ever reply. I've been thinking about it more today and also discussing it more on the autoconf side: https://lists.gnu.org/archive/html/autoconf-patches/2025-05/msg00012.html. The gist is that there's a (very unlikely) case we could hurt, and while it's possible to detect that, it seems like it's more worthwhile to pursue fixing it on the GCC side: https://gcc.gnu.org/PR84995. I'll withdraw the patch, at least for now. cheers, sam
