On Jul 10, 2007, at 01:11, Kai Ruottu wrote:
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" !
Hi,
Thanks for the response. Just to make sure I recompiled binutils to
make sure it was using the same sysroot directory that I was handing
the gcc build. Here's the configure that was used to generate binutils:
../configure --host=i486-linux-gnu --build=i486-linux-gnu --
target=arm-linux-gnu --prefix=/usr --with-sysroot=/usr/arm-linux-gnu
And to make gcc, the configure statement was:
../gcc-4.1.2/configure --prefix=/usr/local --enable-languages=c,c++ --
enable-shared --with-system-zlib --without-included-gettext --enable-
threads=posix --enable-nls --with-gxx-inclue-dir=/usr/include/c++/
4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-
clocale=gnu --enable-libstdcxx=debug --target=arm-linux-gnu --with-
sysroot=/usr/arm-linux-gnu
This time I chose to do a manual recompile of gcc, instead of the
package maintainer's version. However, it gives me this error:
/mnt/stuff/Laine/gcc-4.1-4.1.2.orig/gccbld/./gcc/xgcc
-B/mnt/stuff/Laine/gcc-4.1-4.1.2.orig/gccbld/./gcc/
-B/usr/local/arm-linux-gnu/bin/ -B/usr/local/arm-linux-gnu/lib/
-isystem /usr/local/arm-linux-gnu/include
-isystem /usr/local/arm-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map
-o ./libgcc_s.so.1.tmp libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o
libgcc/./_umodsi3_s.o libgcc/./_modsi3_s.o libgcc/./_dvmd_lnx_s.o
libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o
libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o
libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o
libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_fixdfdi_s.o
libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_fixxfdi_s.o
libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixtfdi_s.o
libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_divdi3_s.o
libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o
libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o
libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o
libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o
-lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv
-f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi &&
mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s
libgcc_s.so.1 ./libgcc_s.so
/usr/bin/arm-linux-gnu-ld: cannot find /usr/arm-linux-gnu/lib/libc.so.6
inside /usr/arm-linux-gnu
collect2: ld returned 1 exit status
So, it looks like this time it's trying to find libc.so.6 in /usr/arm-
linux-gnu/usr/arm-linux-gnu-lib/libc.so.6 Why would it do that?
In the end I'd like to build a Debian package for all of the
toolchain parts, which is why I'm using --prefix=/usr. The binutils
configure is actually from a slightly tweaked build of the building
of the Debian package that uses --with-sysroot.
Thanks for your help so far, I'm really newb-ish at this stuff.
-Laine Walker-Avina
