Cross gcc build problem

[Kai Ruottu]

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" !