Laine Walker-Avina wrote:
On Jul 06, 2007, at 14:31, Brian Dessent wrote:
Laine Walker-Avina wrote:
stage1/xgcc -Bstage1/ -B/usr/arm-linux-gnu/bin/ -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -o
build/genmodes \
build/genmodes.o
build/errors.o ../build-arm-linux-gnu/libiberty/libiberty.a: could not read symbols:
File in wrong format
The build infrastructure is confused about where to use target tools and
where to use build/host tools.
Yeah, you're right. All of the .o files in libiberty.a are i386-elf
and not ARM.
In '$BUILD/libiberty' they should be, this libiberty is for the
build/host platform!
The log also tells that you are doing something similar (and so very
weird) with a native GCC build, a cross GCC
build doesn't involve any 'make bootstrap', only a 'make' with a
pre-existing build/host GCC to produce the new
cross GCC....
BTW, how you did configure the target binutils? Using just the same
'--prefix=$prefix' with the GCC configure
is the assumption :
Here's the configure statement I used:
../src/configure -v --enable-languages=c,c++ --prefix=/usr
The '--prefix=/usr' is usual in a native GCC build. Used in a cross GCC
build that means putting those
'$target-<tool>'s into '/usr/bin' ('$prefix/bin') ! Quite many want to
separate the local self-built apps
from those coming with the original system and '/usr/bin' definitely is
one of the places for the base
system... The default $prefix is '/usr/local' (no '--prefix=something'
used in configure)....
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-checking=release arm-linux-gnu
^^^^^^^^^^^^^
This is an ancient and obsolete way of writing --target=arm-linux-gnu.
I'm not sure if it's the cause of your problem or not, but you should
definitely spell out --target and not just give a target triplet as a
naked parameter.
Tried that and it is still building libiberty as i386 and trying to
link it together with ARM files.
Where on earth it is trying to do this? Almost all the '.o's produced
into the '$BUILD/gcc'
are for the build/host, only the 'crtbegin.o' and 'crtend.o' are for the
target, just as the objects
in '$BUILD/gcc/libgcc'. Linking with $target objects should happen only
for the 'libgcc_s.so.1'
and then the $target-prefixed binutils taken from $prefix/bin should be
used....
>> I have the arm-linux-gnu binutils installed as well as the native
arm libc and headers.
The obvious question then is: Where did you put the target binaries and
the target C library?
What else you did with the target C library? How you arranged the
native '/lib' and '/usr/lib'
install scheme onto the cross host? Usually people haven't any clues
for this but the current
recommendation is to use the '--with-sysroot=$sysroot' in the binutils
and GCC configures
and then put the "native" target C library and other required target
stuff into:
$sysroot/lib
$sysroot/usr/include
$sysroot/usr/lib
$sysroot/usr/X11R6/include
$sysroot/usr/X11R6/lib
etc. Then both the binutils and GCC should find it automatically....
Any clue what would cause this?
Please elaborate the "this" !
