Re: Compiling GCC with C and C++ for an ARM platform

["Rob Emanuele" <poorarm at shoreis dot com>]

Brain and company,

Thank you very much for the information.  I'm going to make a go of
C++ probably today.  Is there documentation for building with
--with-newlib?  (If not I'd be happy to write some.)  This is to
produce code for bare-metal, an STR912 processor.  I may try changing
the ABI also.

Thanks,

Rob

On Wed, Apr 9, 2008 at 8:22 PM, Brian Dessent <brian@dessent.net> wrote:
> Rob Emanuele wrote:
>
>  > compiler) on a linux x86_64 host for an arm-elf target.  I would like
>  > to know if it is possibe to build a version of GCC with C++ for the
>  > arm and is arm_elf the right target?  Would I be better off using
>  > arm-none-eabi?  What is the difference?  Details of the error building
>
>  Well, what ABI does your target use?  If it is bare metal and uses the
>  old ABI, it's arm-elf, if it uses EABI it's arm-none-eabi.  If it is not
>  bare metal but GNU/Linux with EABI the target is
>  arm-none-linux-gnueabi.  The EABI makes a lot of improvements over the
>  OABI, notably in floating point performance, being able to mix hard and
>  softfloat, better syscall performance, etc.  You'll have to google for
>  more details.
>
>
>  > configure: error: No support for this host/target combination.
>  > make[3]: *** [configure-target-libstdc++-v3] Error 1
>
>  The problem you have run into is common.  In order to configure
>  libstdc++, aspects of the target's libc need to be known in order to
>  know what features of libstdc++ to enable.  So that's the first
>  question: what libc are you using?
>
>  For a native configuration, this is simple: the configure script can
>  perform compile, link, and execute tests to determine these things.
>
>  But it's a different story when building a cross compiler, epspecially
>  for bare metal targets.  These usually require things outside of the
>  scope of gcc in order to link: crt*.o, linker script, syscall stubs,
>  etc.  So the policy is that link tests aren't allowed in libstdc++
>  configure for crosses to bare metal.
>
>  The question remains then, how is libstdc++ to be configured?  There are
>  two general ways: A) --with-newlib, and B) crossconfig.m4.
>
>  If your target uses newlib then you are set, since newlib is
>  special-cased.  Just make sure the newlib headers are in the proper
>  location[1] before starting the build, and supply --with-newlib when
>  configuring to indicate that you're using newlib.  The rest should just
>  work.  (Note that there currently is a bug in 4.3 in this area that
>  causes it not to "just work", but there's a straightforward fix[2] for
>  that.)
>
>  If you're not using newlib as your libc, then you need to specify the
>  characteristics of your libc in crossconfig.m4.  And in fact if you look
>  at that file, the default case contains a fallthrough of
>  "AC_MSG_ERROR([No support for this host/target combination.])", exactly
>  what you're seeing.
>
>
>  > Is this target just not complete or is it obselete?
>
>  Neither.  It's just that you can't expect libstdc++ to configure itself
>  with no information on the target libc.
>
>
>  > The other constraint for building is that I must disable libssp when I
>  > configure GCC.  Without disabling libssp the compile/config produces
>  > these warnings and eventually fails:
>
>  Yes, that's a deficiency that should probably be improved, but the
>  --disable-libssp workaround is simple enough.  If there's not a PR open
>  for that I'd file one.
>
>  Brian
>
>  [1] If using a sysroot, then put them in the corresponding place there,
>  otherwise $prefix/$target/include.  Sometimes you have to symlink
>  $prefix/$target/sys-include to ../include as well.  Or, you can use
>  --with-headers=location to spell it out explicitly.
>
>  [2] Skip AC_LIBTOOL_DLOPEN for newlib targets, see
>  <http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01560.html> for the
>  general idea.
>