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

[H.J. Lu]

On Tue, Jun 26, 2012 at 3:39 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Jun 26, 2012, at 2:04 PM, Alexandre Oliva wrote:
>> I test i686-linux-gnu in a presumably unusual setting
>
> I like the setup and testing...
>
>> This worked fine for regression testing, but I've recently realized
>> (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite
>> failures (before and after, so no regression), because the 32-bit LTO
>> plugin built in this setting can't possibly be used by the 64-bit linker
>> installed on the system.  Obviously, passing -melf_i386 to the linker
>> through the wrapper is not enough for it to be able to dlopen a 32-bit
>> plugin ;-)
>
> So, let's kick this back to the gcc list for all the interested parties to chime in on...  I'd rather have 5 interested people architect the right, nice solution that is engineered to work and then use it.  I don't like any of the solutions so far.  On darwin, we'd just have the plugin and even ld be fat and then one could load that on any architecture, but that's cheating.  H.J.'s solution seems like the most reasonable short term solution, though, I kinda hate all the magic bits one needs for the environment.  Hum, thinking about this for a second...  If we build the plugin after sensing the 64-bitness of ld, using the flags appropriate for the linker...  That's be nice...  if people don't want to do that, then failing the build early when mismatched and simply documenting that one must have a 32-bit linker given to gcc for the build to work, at least would be more honest.

Bootstrap/test -m32/-mx32 with LTO on -m64 is similar to cross-compile,
in the sense that the native linker may not work with plugin.  We just
need to make the right linker available to GCC. My kludge uses PATH.
One can also include binutils source in GCC source tree.

-- 
H.J.