On Sat, Oct 12, 2013 at 12:20 PM, Thomas Schwinge
<tho...@codesourcery.com> wrote:
> Hi!
>
> This is a bit of a weird scenario -- but it is supposed to work fine in
> my opinion (but doesn't).
>
> I have a GNU toolchain as 32-bit x86 GNU/Linux executables, configured to
> to generate code for 32-bit x86 by default, and using -m64 for x86_64.
>
> This toolchain I'm using on a x86_64 system (which can execute 32-bit
> executables) to build a *native* GCC, that is I'm using the 32-bit
> toolchain to build a x86_64 GCC (configuring with CC='gcc -m64' CXX='g++
> -m64'). I intend to continue using the 32-bit toolchain's linker, which
> also is a 32-bit executable (GNU ld). That one also defaults to x86
> code, but can handle the x86_64 case fine if passed -m elf_x86_64, which
> GCC does.
>
> That the linker is a 32-bit executable is an implementation detail that
> is not important generally: it's a separate process living in its own
> address space. However it becomes relevant in the case of linker
> plugins: the native x86_64 GCC that I'm building also builds a x86_64
> lto-plugin, which the 32-bit ld cannot load:
>
> $ gcc/xgcc -B[...] [...]/gcc.c-torture/execute/ieee/20000320-1.c [...]
> -flto [...]
> [...]/ld: [...]/gcc/liblto_plugin.so: error loading plugin:
> [...]/gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
> collect2: error: ld returned 1 exit status
>
> So, aside from building a 64-bit ld (which is the "lame" alternative), I
> now need to teach GCC's build system that the lto-plugin may need special
> configuration: CC='gcc -m32' -- and possibly its own build of libiberty,
> too, which it may depend on (but doesn't in my case, so I might cut this
> short, and just error out). Instead of auto-detecting the linker's
> architecture (and then, what to do with that information?), I intend to
> make this a manual process (so, some new top-level configure
> argument(s)). Adding yet another set of {...,CC,...}_FOR_[something] is
> probably overkill -- I'll try to find something simpler.
>
> Any comments on this scenario?
I suppose nobody thought of this but I wouldn't call it a scenario that
is desired to support either ;)
Richard.
>
> Grüße,
> Thomas
