Error compiling arm-elf-gcc-4.5.0

Kai Ruottu kai.ruottu@wippies.com
Wed Apr 21 14:52:00 GMT 2010


21.4.2010 10:17, Massimiliano Cialdi kirjoitti:

> more precsely I have done the following steps:
> export INSTALLDIR=/usr/local/cross-gcc-arm-elf-4.5.0
>
> mkdir build-binutils
> cd build-binutils
> ./binutils-2.20.1/configure --target=arm-elf --prefix=${INSTALLDIR}
> make -j5 all
> sudo make install
>
> cd ../gcc-4.5.0
> ln -s ../newlib-1.18.0/newlib .
> ln -s ../newlib-1.18.0/libgloss .
> cd ..
> mkdir build-gcc&&  cd build-gcc
> ./gcc-4.5.0/configure --enable-languages=c,c++ --target=arm-elf
> --with-gnu-as --with-gnu-ld –prefix=${INSTALLDIR} --with-newlib
> --disable-shared --enable-newlib –enable-multilib --enable-interwork
> --disable-threads --disable-nls --enable-libstdcxx-allocator=malloc
> --with-mpc=/usr/local/mpc

I tried the same with almost the same options, the differences being:

- no '--with-gnu-as --with-gnu-ld', they should be vain in this case
   (no default "proprietary ARM Inc. 'as' and 'ld' tools")

- no '--with-mpc=', I symlinked the 'mpc-0.8.1' sources as 'mpc' in
   the main gcc-4.5.0 source dir

Furthermore :

- 'newlib' and 'libgloss' symlinked from 'newlib-1.17.0' in the main
   gcc-4.5.0 source dir

- 'gmp-4.3.1' and 'mpfr-2.4.1' symlinked as 'gmp' and 'mpfr' in
   the main gcc-4.5.0 source dir

- a cross gcc-3.4.6 for an earlier Linux distro was used as 'CC'

- binutils-2.19.51.0.8 was used as the target binutils (made on 2009)

> I have the error:
> checking for exported
> symbols... /usr/local/cross-gcc-arm-elf-4.5.0/arm-elf/bin/objdump:
> conftest: File format not recognized
> checking for
> -rdynamic... /usr/local/cross-gcc-arm-elf-4.5.0/arm-elf/bin/objdump:
> conftest: File format not recognized

Nothing like this happened, the 'gcc/config.log' tells :

----------- clip --------------------
configure:24660: checking __stack_chk_fail in target C library
configure:24723: result: no
configure:24821: checking whether to enable maintainer-specific portions 
of Makefiles
configure:24831: result: no
configure:25163: checking for exported symbols
configure:25170: checking for -rdynamic
configure:25182: checking for library containing dlopen
----------- clip --------------------

But also :

----------- clip --------------------
gcc_cv_nm=/usr/local/arm-elf/bin/nm
gcc_cv_objdump=/usr/local/arm-elf/bin/objdump
----------- clip --------------------

So the 'arm-elf' targeted 'objdump' would be used to investigate
the executables made for the $host !  Sounds being a BUG !!!!

But what really happens when trying to do something as stupid :

[root@Dell gcc]# /usr/local/arm-elf/bin/objdump -T xgcc

xgcc:     file format elf32-little

DYNAMIC SYMBOL TABLE:
00000000      DF *UND*  00000042  GLIBC_2.0   wait4
00000000      DF *UND*  00000059  GLIBC_2.0   ferror
00000000      DF *UND*  00000167  GLIBC_2.0   strchr
00000000      DF *UND*  000001b2  GLIBC_2.1   fdopen
08076300 g    DO .bss   00000004  GLIBC_2.0   __ctype_tolower
00000000      DF *UND*  00000035  GLIBC_2.1   mempcpy
00000000      DF *UND*  0000002e  GLIBC_2.0   getpid
00000000      DF *UND*  00000050  GLIBC_2.0   strdup
00000000      DF *UND*  000000aa  GLIBC_2.0   _obstack_begin
00000000      DF *UND*  0000003c  GLIBC_2.0   write
00000000      DF *UND*  0000008f  GLIBC_2.1   fputs_unlocked
00000000      DF *UND*  0000002f  GLIBC_2.0   strcmp
00000000      DF *UND*  00000036  GLIBC_2.0   close
00000000      DF *UND*  00000045  GLIBC_2.0   vfork
00000000      DF *UND*  0000010a  GLIBC_2.0   strsignal

and so on....

The binutils-2.19.51.0.8 seems to 'grok' also the $host
binaries but the "bleeding edge" 2.20.1 seeminly not :(

> So I first build and install binutils 2.20.1 for arm without problems,

These steps seem to work but the "use" step doesn't...
Your first workaround could be to downgrade to 2.19.51,
for instance to the Linux-binutils releases in :

ftp://ftp.kernel.org/pub/linux/devel/binutils/

aimed for Linux hosts (and targets too). And then
report this "feature" as a bug... Maybe the latest,
'binutils-2.19.51.0.14' still "works"...



More information about the Gcc-help mailing list