public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Error compiling arm-elf-gcc-4.5.0
@ 2010-04-20 15:23 Massimiliano Cialdi
  2010-04-20 16:37 ` Kai Ruottu
  0 siblings, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2010-04-20 15:23 UTC (permalink / raw)
  To: gcc-help

I have configured as follows:
configure --enable-languages=c,c++ --target=arm-elf --with-gnu-as
--with-gnu-ld --prefix=path-to/arm-elf-gcc-4.5.0 --with-newlib
--disable-shared --enable-newlib --enable-multilib --enable-interwork
--disable-threads  --disable-nls --enable-libstdcxx-allocator=malloc
--with-mpc=/usr/local/mpc

I have static version of mpc 0.8.1

when I make all I get the following error:

Links are now set up to build a cross-compiler
from x86_64-unknown-linux-gnu to arm-unknown-elf.
checking for exported symbols...
path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump: conftest: File format not
recognized
checking for -rdynamic... path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump:
conftest: File format not recognized

my system is ubuntu 9.10 64 bit with
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

binutils:
GNU ld (GNU Binutils for Ubuntu) 2.20

what is wrong with it?

thanks

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-20 15:23 Error compiling arm-elf-gcc-4.5.0 Massimiliano Cialdi
@ 2010-04-20 16:37 ` Kai Ruottu
  2010-04-21  7:17   ` Massimiliano Cialdi
  0 siblings, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2010-04-20 16:37 UTC (permalink / raw)
  To: gcc-help

20.4.2010 11:49, Massimiliano Cialdi kirjoitti:

> I have configured as follows:
> configure --enable-languages=c,c++ --target=arm-elf --with-gnu-as
> --with-gnu-ld --prefix=path-to/arm-elf-gcc-4.5.0

The given $prefix should be some 'absolute' pathname, the default is
'/usr/local' when no '--prefix=$prefix' is given. Yours is 'relative'
to some directory.

> when I make all I get the following error:
>
> Links are now set up to build a cross-compiler
> from x86_64-unknown-linux-gnu to arm-unknown-elf.
> checking for exported symbols...
> path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump: conftest: File format not
> recognized
> checking for -rdynamic... path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump:
> conftest: File format not recognized

Hard to say what is the search root for these, probably the main $BUILD
directory. In any case there seems to be nothing which the configure
script expects, here an 'objdump' for the 'arm-elf' target...

> my system is ubuntu 9.10 64 bit with
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
>
> binutils:
> GNU ld (GNU Binutils for Ubuntu) 2.20

Of course you should first have binutils for 'arm-elf' in the
'$prefix/bin' (for humans and this dir in PATH) and in
'$prefix/arm-elf/bin' (for the GCC to be built). The
'path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump' shows this
scheme with your given $prefix and $target values.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-20 16:37 ` Kai Ruottu
@ 2010-04-21  7:17   ` Massimiliano Cialdi
  2010-04-21 13:21     ` Kai Ruottu
  0 siblings, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2010-04-21  7:17 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

Il giorno mar, 20/04/2010 alle 17.23 +0300, Kai Ruottu ha scritto:
> > I have configured as follows:
> > configure --enable-languages=c,c++ --target=arm-elf --with-gnu-as
> > --with-gnu-ld --prefix=path-to/arm-elf-gcc-4.5.0
> 
> The given $prefix should be some 'absolute' pathname, the default is
> '/usr/local' when no '--prefix=$prefix' is given. Yours is 'relative'
> to some directory.
path-to/arm-elf-gcc-4.5.0
is only a placeholder, not the true prefix path.
The actual prefix is /usr/local/cross-gcc-arm-elf-4.5.0


> Of course you should first have binutils for 'arm-elf' in the
> '$prefix/bin' (for humans and this dir in PATH) and in
> '$prefix/arm-elf/bin' (for the GCC to be built). The
> 'path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump' shows this
> scheme with your given $prefix and $target values.
Yes, I have previously built binutils 2.20.1 for arm target

MC

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-21  7:17   ` Massimiliano Cialdi
@ 2010-04-21 13:21     ` Kai Ruottu
  2010-04-21 13:44       ` Massimiliano Cialdi
  0 siblings, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2010-04-21 13:21 UTC (permalink / raw)
  To: Massimiliano Cialdi; +Cc: gcc-help

20.4.2010 18:23, Massimiliano Cialdi kirjoitti:

> Il giorno mar, 20/04/2010 alle 17.23 +0300, Kai Ruottu ha scritto:
>>> I have configured as follows:
>>> configure --enable-languages=c,c++ --target=arm-elf --with-gnu-as
>>> --with-gnu-ld --prefix=path-to/arm-elf-gcc-4.5.0
>>
>> The given $prefix should be some 'absolute' pathname, the default is
>> '/usr/local' when no '--prefix=$prefix' is given. Yours is 'relative'
>> to some directory.
> path-to/arm-elf-gcc-4.5.0
> is only a placeholder, not the true prefix path.
> The actual prefix is /usr/local/cross-gcc-arm-elf-4.5.0
 >
 > Yes, I have previously built binutils 2.20.1 for arm target


Ok...

 > when I make all I get the following error:
 >
 > Links are now set up to build a cross-compiler
 > from x86_64-unknown-linux-gnu to arm-unknown-elf.
 > checking for exported symbols...
 > path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump: conftest: File format not
 > recognized
 > checking for -rdynamic... path-to/arm-elf-gcc-4.5.0/arm-elf/bin/objdump:
 > conftest: File format not recognized

Probably the native 'objdump' should be used here, not the 'arm-elf'
one... The code in 'gcc/configure' for this seems to be the :

-------------------- 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 native GCC compiles and links a program and then the executable
will be looked with 'objdump'...

So my guess is that you have somehow messed your environment :(
For instance putting the '$prefix/$target/bin' into your PATH
before the '/usr/bin' where the native 'objdump' usually is...

Why you would do a weird thing like this, I cannot guess... If
some instruction somewhere told to do this, please tell us!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-21 13:21     ` Kai Ruottu
@ 2010-04-21 13:44       ` Massimiliano Cialdi
  2010-04-21 14:52         ` Kai Ruottu
  0 siblings, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2010-04-21 13:44 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

Il giorno mar, 20/04/2010 alle 19.06 +0300, Kai Ruottu ha scritto:
> Probably the native 'objdump' should be used here, not the 'arm-elf'
> one... The code in 'gcc/configure' for this seems to be the :
> 
> -------------------- 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 native GCC compiles and links a program and then the executable
> will be looked with 'objdump'...
> 
> So my guess is that you have somehow messed your environment :(
> For instance putting the '$prefix/$target/bin' into your PATH
> before the '/usr/bin' where the native 'objdump' usually is...
> 
> Why you would do a weird thing like this, I cannot guess... If
> some instruction somewhere told to do this, please tell us!
No path variable is correctly set.

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
make -j5 all


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


$ echo $PATH
/opt/jdk1.6/bin:/opt/eclipse:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

So I first build and install binutils 2.20.1 for arm without problems,
then I try to build gcc (as said I have satic mpc 0.8.1 library) with
that error

bye

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-21 13:44       ` Massimiliano Cialdi
@ 2010-04-21 14:52         ` Kai Ruottu
  2010-04-22 13:55           ` Kai Ruottu
  0 siblings, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2010-04-21 14:52 UTC (permalink / raw)
  To: Massimiliano Cialdi; +Cc: gcc-help

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
  2010-04-21 14:52         ` Kai Ruottu
@ 2010-04-22 13:55           ` Kai Ruottu
       [not found]             ` <BLU124-W8C43C3FDBE76D44D97CBDC2080@phx.gbl>
  0 siblings, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2010-04-22 13:55 UTC (permalink / raw)
  To: gcc-help

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...

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Error compiling arm-elf-gcc-4.5.0
       [not found]             ` <BLU124-W8C43C3FDBE76D44D97CBDC2080@phx.gbl>
@ 2010-04-23 17:31               ` Kai Ruottu
  0 siblings, 0 replies; 8+ messages in thread
From: Kai Ruottu @ 2010-04-23 17:31 UTC (permalink / raw)
  To: Soumya Prasad Ukil; +Cc: gcc-help, Massimiliano Cialdi

22.4.2010 13:15, Soumya Prasad Ukil kirjoitti:

> fuck u
> regards,
> soumya prasad ukil
> Mobile - 9920942798
>
 > > -------------------- 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
> > -------------------- 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...

The new 'plugins' has caused a lot discussion on the GCC developer list,
mainly because many $build/$host systems don't even have any 'objdump',
MacOS X and Solaris for instance... This bug is only one nuance more
but when asking there, it became clear that the goal really wasn't to
use the $target-objdump but the host one. But if the host one is really
missing and the target one however exists, then why not use that...

In any case I too am waiting for the final well-thought solution...

But :

One possible workaround more would be to try producing bi-arch
binutils, in the problem x86_64 host and arm-elf target case using :

.../configure --target=arm-elf --enable-targets=x86_64-linux-gnu

Then the arm-elf targeted 'objdump' should also grok x86_64 binaries. 
And not fix anything yet in the gcc-4.5.0 sources.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-04-23 10:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-20 15:23 Error compiling arm-elf-gcc-4.5.0 Massimiliano Cialdi
2010-04-20 16:37 ` Kai Ruottu
2010-04-21  7:17   ` Massimiliano Cialdi
2010-04-21 13:21     ` Kai Ruottu
2010-04-21 13:44       ` Massimiliano Cialdi
2010-04-21 14:52         ` Kai Ruottu
2010-04-22 13:55           ` Kai Ruottu
     [not found]             ` <BLU124-W8C43C3FDBE76D44D97CBDC2080@phx.gbl>
2010-04-23 17:31               ` Kai Ruottu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).