Re: Cross gcc build problem

[Kai Ruottu <karuottu at mbnet dot fi>]

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