21.4.2010 16:21, Kai Ruottu kirjoitti:
>> 21.4.2010 10:17, Massimiliano Cialdi kirjoitti:
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
----------- 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 :(
I tried the most uptodate binutils-2.20.51.0.8 and they
"worked" too with this. But not with newlib-1.17.0 ! Some
'.S' source file in 'newlib-1.17.0/libgloss' wasn't
understood by the new 2.20.51.0.8 'as'. Upgrading to
newlib-1.18.0 fixed this.
So the real problem seems to be that on a 64-bit x86_64
host the arm-elf-objdump doesn't understand the x86_64-linux-gnu
binaries !
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"...
A bug report, #43847, was sent by me... I also tried to see
how the 'gcc_cv_objdump' is calculated in 'gcc/configure' and
if fixing it to point to the $host one could be an easy job.
The first impression was that a big mistake was done, the 'gcc' subdir
should be purely $host specific, producing the GCC binaries for
the $host, but the calculations tried to find the OBJDUMP_FOR_TARGET,
a just built $target-objdump etc. :(
So fixing the code maybe isn't that easy and quick because the whole
idea is wrong. But one could invent some possible workarounds like :
- defining "OBJDUMP_FOR_TARGET=objdump" in environmen before running
'configure'
- fixing the '$gcc_cv_objdump' to be '$ac_cv_prog_OBJDUMP' in the
buggy code :
-------------------- clip -----------------------------------
pluginlibs=
if test x"$enable_plugin" = x"yes"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for exported
symbols" >&5
$as_echo_n "checking for exported symbols... " >&6; }
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
if $gcc_cv_objdump -T conftest | grep foobar > /dev/null; then
: # No need to use a flag
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -rdynamic" >&5
$as_echo_n "checking for -rdynamic... " >&6; }
${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest >
/dev/null 2>&1
if $gcc_cv_objdump -T conftest | grep foobar > /dev/null; then
pluginlibs="-rdynamic"
else
enable_plugin=no
fi
fi
-------------------- clip -----------------------------------
The assumption is that the GCC developers know what they are doing,
so maybe using '$gcc_cv_objdump' instead of '$ac_cv_prog_OBJDUMP'
was only a stupid mistake, a thing happening to everyone now and
then...
