This is the mail archive of the
mailing list for the binutils project.
Problem with building cross-compilers: how to fix?
- From: Nix <nix at esperi dot org dot uk>
- To: binutils at sources dot redhat dot com
- Date: Sat, 28 Oct 2006 23:19:08 +0100
- Subject: Problem with building cross-compilers: how to fix?
So I've upgraded to binutils from CVS (mostly for the sake of
DT_GNU_HASH support and the nice ARM improvements) and I'm trying to
build a cross-compiler (to arm-unknown-elf, from i686-pc-linux-gnu).
In the past, I've been able to build with
to force the libbfd and libopcodes shared libraries into subdirectories
and wire them into the cross-compiler's rpath so they don't collide
with the host's copies.
Alas this seems to have stopped working. Here's the failure, which
happens almost immediately after libbfd is linked:
Configuring in ./opcodes
configure: loading site script /home/compiler/.configure/config.site
site-config script adjustments... (linker flags) (assembler flags) (Java compiler flags) (F77 compiler flags) (F90 compiler flags) (Objective C compiler flags)
configure: loading cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... arm-unknown-elf
checking for i686-pc-linux-gnu-gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [configure-opcodes] Error 1
(pig-ugly site-config file available on request but I doubt it's
implicated here: binutils 2.17 built, after all).
The error in config.log:
configure:1786: checking for C compiler default output file name
configure:1789: gcc -O2 -fomit-frame-pointer -march=athlon-4 -pipe -D__NO_STRING_INLINES -D__NO_MATH_INLINES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -ffast-math -s -Wl,--enable-new-dtags -Wl,-O1 -Wl,-z,relro conftest.c >&5
Fatal error: selected target format 'elf32-i386' unknown
configure:1792: $? = 1
The problem is that the LD_LIBRARY_PATH has been set to
This is merrily picking up the libbfd from the just-built
cross-compiler, and trying to use it to build things on the host!
Obviously this will never work (but it worked with 2.17, and now I look
at it I can't see how: you have to pick up the cross-bfd library when
you run things, but you can't pick it up or you'll break the native
compiler). Equally obviously everyone else is building cross-compilers
in a completely different way and I've been doing something wrong for
years. Is --enable-shared just not expected to work with cross-binutils
builds, or something?
`When we are born we have plenty of Hydrogen but as we age our
Hydrogen pool becomes depleted.'