On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
> On Jun 27, 2012, Mike Stump <mikest...@comcast.net> wrote:
>
> > On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
> >> Why? We don't demand a working plugin. Indeed, we disable the use of
> >> the plugin if we find a linker that doesn't support it. We just don't
> >> account for the possibility of finding a linker that supports plugins,
> >> but that doesn't support the one we'll build later.
>
> > If this is the preferred solution, then having configure check the
> > 64-bitness of ld and turning off the plugin altogether on mismatches
> > sounds like a reasonable course of action to me.
>
> I'd very be surprised if I asked for an i686 native build to package and
> install elsewhere, and didn't get a plugin just because the build-time
> linker wouldn't have been able to run the plugin.
Not disable plugin support altogether, but disable assuming the linker
supports the plugin. If user uses explicit -f{,no-}use-linker-plugin,
it is his problem to care that the linker has support. But the problem
is that when build-time ld is new enough gcc assumes it has to support
the plugin. And that is not the case.
Jakub
