Cross gcc build problem
Laine Walker-Avina
lwalkera@ieee.org
Tue Jul 10 20:57:00 GMT 2007
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
More information about the Gcc-help
mailing list