On Tue, Jun 26, 2012 at 06:04:54PM -0300, Alexandre Oliva wrote:
> I test i686-linux-gnu in a presumably unusual setting: it's an
> x86_64-linux-gnu system, and I've configured the GCC build to use as
> builddev tools wrapper scripts for as, ld, gnatmake and gcc that add
> flags that make them default to 32-bit.
>
> 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 ;-)
>
> I'm considering installing alternate 32-bit tools on my system for
> better testing, but I figured I'd betetr fix the test harness before
> tackling this: if we find that the LTO plugin doesn't work, we'd better
> not use -flto without -fno-use-linker-plugin, to avoid such spurious
> failures as GCC attempts by its own initiative to use the linker plugin.
>
> At first I wished there was a simpler, off-band way to tell it not to
> use the LTO plugin, that didn't pollute the command line or the test
> results, but before I even looked around for some such way, I figured it
> would be useful to have information that the linker plugin was not used
> in a particular test run, so I went for this patch instead.
I don't think testsuite harness is the right spot to deal with it, IMNSHO
gcc just shouldn't default to using the linker plugin solely based on
ld --version, it should take into account whether that linker can load
the plugin.
Right now I'm using the following hack in my ld wrapper script for
i686-linux builds on x86_64:
#!/bin/sh
case "$*" in
--version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
EOF
exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
(it lies about the ld version and thus gcc doesn't assume ld plugin will
work).
Jakub
