Help needed building GCC for powerpc-eabi

Jeff Lasslett
Fri Aug 4 01:53:00 GMT 2006

Hi Michael,

Michael Eager wrote:
> Jeff Lasslett wrote:
>> If I use --target=powerpc-eabi then I have problems.  
>> checking for shared libgcc... configure: error: Link tests are not 
>> allowed after GCC_NO_EXECUTABLES.
>> make[1]: *** [configure-target-libstdc++-v3] Error 1
>> make[1]: Leaving directory `/home/jeff/gnu/build/gcc'
>> make: *** [all] Error 2
> See my message:
> Also you probably want to specify --disable-libssp.

I followed those threads and came to the conclusion that I want
--disable-shared.  I also took your advice and added --disable-libssp.

Anyway, thanks to the help you pointed me to, I have been able to
build a powerpc-eabi targetted toolchain.

Thanks for you help Michael.



What follows is for the benefit of anyone else running up against
the aforementioned problem when compiling powerpc-eabi targetted GCC.
It's an extract from notes I am keeping as I progress toward a fully
operational GNU toolchain and newlib for developing software for my
embedded system.


This morning I received an email from the gcc-help list that points to an
archived thread from earlier this year.  In that thread, the problem that I
am having building powerpc-eabi was discussed at some length.

The email I received contained the following link ...

... which in turn contains the following link ...

Following this latter thread leads to the following interesting nuggets ... contains ...

"You appear to be assuming that the powerpc-eabi compiler should be able to
  link without further information. This is not the case; powerpc-eabi is one
  of the targets that cannot link by default, and you need to use a more
  specific target (eg. powerpc-freebsd or powerpc-eabisim) if you want it to
  be able to link without an extra flag (like -myellowknife or -mads or -msim).
  This is so you can have one toolchain that targets many incompatible boards.

  However, it is a bug that libstdc++-v3 does not build on powerpc-eabi. It
  should not be trying to link anything; its final product is a .a archive." contains ...

"> Or default to one of them (probably -msim)? "

"That's what the target powerpc-eabisim is for. powerpc-eabi is specifically
  to prevent it defaulting to anything, and force the caller to make a choice,
  so that you can detect cases where, for instance, the libstdc++ configure
  process has broken.

  It doesn't produce an 'informative error message' like that because the user
  is also allowed to supply their own crt* files, like

         gcc mycrt0.o foo.c -o foo

  in case one of the existing boards isn't what they want."

SO it would seem that the configure scripts for libstdc++-v3 are broken for 
the powerpc-eabi target.  That target isn't supposed to produce runnable code 
without further command line options from the user indicating what runtime it 
should link against.

That's what we want.  We have our own runtime code that we will want to link 
our application code to.

So I added --disable-shared to the final gcc configure command line.  Now it
doesn't try to build shared libs (which require linking).  That's fine as our
app is all statically linked anyway.  We have no way of handling shared libs
in the logger.

I also added --disable-libssp.  libssp constitutes a gcc extension called
'stack smashing protocol'.  The lib is fairly new and experimental.  We won't
need it.

So now my final gcc configure command line looks as follows:-

$ ../../src/gcc-4.1.1/configure --target=$TARGET --prefix=$PREFIX \
--with-gnu-as --with-gnu-ld --with-newlib --disable-libssp \
--disable-shared --enable-languages=c,c++

$ make all install 2>&1 | tee make.log yielded a powerpc-eabi-gcc.

It worked.

More information about the Gcc-help mailing list