Paul Eggert <egg...@cs.ucla.edu> writes:
> On 2025-05-15 08:41, Zack Weinberg wrote:
>> Is there
>> a situation where gcc-{ar,ranlib} are available on the PATH but
>> *should not* be used in preference to plain {ar,ranlib}?
>
> Yes, use gcc-ar only when compiling with GCC. If you're compiling with
> Clang you should use llvm-ar. I don't know of other compilers having
> this issue, so for other compilers you should use plain ar.
This is sort of the case and sort of not. I'm only aware of a few fringe
environments where `ar` on PATH is actually llvm-ar (i.e. systems using
Clang where they may now use `gcc-ar` with this change would be using
`ar` beforehand which is still from GNU Binutils).
Now, I _think_ that in the "we have plugins" case *and* LLVM's own
plugin is installed, `ar` and `ranlib` will work fine. But in the "we
don't" case, you indeed want `llvm-ar` and `llvm-ranlib` (and they
appear to recommend it anyway:
https://discourse.llvm.org/t/using-llvm-ar-llvm-ranlib-vs-ar-ranlib-for-creating-static-libraries-when-thinlto-is-enabled/49401/3).
.. but on macOS, it appears that's wrong:
https://github.com/python/cpython/issues/87275#issuecomment-1093901266
and `ar` is fine, as it's Apple's.
In summary:
1. In the no-plugin-available case, you're using the LLVM toolchain, and
ar/ranlib are from GNU Binutils, then gcc-ar/gcc-ranlib won't help
but they don't hurt either (the GCC plugin won't claim the relevant
objects).
2. Even with the plugin available which LLVM provides for GNU Binutils
("LLVMgold", ignore the confusing name), they still seem to recommend
you use llvm-ar and llvm-ranlib, which figures.
3. If using the LLVM toolchain and `ar` points to `llvm-ar`, no plugin
is available (which is fine if using `llvm-ar`), and with this patch,
we're now using `gcc-ar` et. al instead, then you may get a build failure.
The latter is the one that matters the most, even if it's rare.
But detecting "genuine GCC" given Clang defines __GNUC__ is a pain, and
our current configure checks don't handle that. There's ways around that
like checking for __clang__ too, but then it really starts to feel like
overcomplication -- especially given the people hitting this have an
easy workaround.
(It's totally doable, just not sure it's worth it.)
I'm inclined to say we leave things as they are and I'll withdraw the
patch accordingly, unless any of the above provokes some fresh ideas?
thanks,
sam
