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.
