pursue fixing it on the GCC side: https://gcc.gnu.org/PR84995.
Egad. I'm glad I'm not on the hook for that stuff :).
I'll withdraw the patch, at least for now.
Duly closing. Thanks Sam. --best, karl.
Karl Berry 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 lik
Hi Sam,
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
Sam James writes:
> GCC requires `ar` 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.
>
> By searching for `gcc-ar` fir
GCC requires `ar` 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.
By searching for `gcc-ar` first, we can make this case work
