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