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?
Grüße,
Thomas
pgp1uslEYFIix.pgp
Description: PGP signature
