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