This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Error compiling arm-elf-gcc-4.5.0
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.