Re: [PATCH] Search for gcc-ar, gcc-ranlib respectively
Nick Bowler <[email protected]> Thu, 15 May 2025 14:11:04 -0400
| Newsgroups | gmane.comp.sysutils.autoconf.patches |
|---|---|
| Message-ID | <j6lesqrjehpj34pypvv4fdkdzkrgqmvfoi3rhpxp45ilto4bav@7t3tcmt6a6n3> |
On Thu, May 15, 2025 at 12:52:17PM +0100, Sam James wrote: > Sam James <[email protected]> writes: > > GCC requires `ar` and `ranlib` to have plugin support when using LTO. While > > the situation has improved as many distributions install the GCC plugin > > to a location that GNU Binutils can automatically find, this isn't required > > and isn't done by default. [...] > (The AC_CHECK_TOOL changes aren't right, needs to be > called-then-checked, but I won't send a v2 yet as still testing it and > want feedback on the idea of it.) If practical to do so, configure should automatically find whatever tools are needed for a successful compilation, so the idea is fine in principle. But I think it is a problem if configure ends up selecting gcc-ar over ar in a scenario when plain 'ar' would work and gcc-ar doesn't. I imagine you will also need to patch libtool to find gcc-nm. At the same time, it's not unreasonable to expect that users who set non-default compilation flags might also need to set a non-default AR, RANLIB, NM, etc. as appropriate for their environment -- so if the configure tests end up too complex, or take too much time, then it's also fine to just pass the buck to the user. Cheers, Nick