Re: [testsuite] don't use lto plugin if it doesn't work

[Mike Stump <mikestump at comcast dot net>]

On Jun 28, 2012, at 12:16 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun 27, 2012, Mike Stump <mikestump@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.

The architecture of the compiler, last I knew it, was to smell out the feature set of the system, including libraries, headers, assemblers and linkers.  It uses this as static configuration parameters for the build.  One is not free to take the built compiler to a differently configured system at run time.

Now, with that as a backdrop, how exactly do you ever plan on using the plugin?  If there is no possible use for it, why then build it?

So, even if there is a way to toggle the feature on, which would mean the plug-in should be built, it should still be off initially, which it isn't.