Dave Nadler wrote: > While I did get a complete set of executables from > the make, I didn't get libgcc, libstdc++, nor did I get > the include files. What am I missing here ? You specified --without-headers which tells the build system that there are no libc headers available, i.e. a completely freestanding compiler. C++ support (and libgcc and libstdc++) require a working, preexisting libc, so that is why it didn't try to build those components. Note that cross-compiling libstdc++ introduces its own measure of difficulty: in order to configure the library correctly a large number of aspects of the target's libc must be determined, and many of these tests are in the form of link tests to see what the library supports. This means you need to be able to link executables when running the libstdc++ configure script, which for a bare metal target generally means you need all of the board support files (CRT/linker script/syscall stubs) existing in a place visible to the newly built compiler. In the specific case of newlib, the build system has a predefined list of what the library supports and so in theory it should be possible to cross-build libstdc++ without being able to link, but only if you're using newlib and only if inform the build system of this fact (--with-newlib.) However the configure scripts are constantly evolving and I think the general consensus is moving toward requiring that for bare metal targets the BSP files be available for building a cross libstdc++ (i.e. requiring link tests again), since otherwise relying on assumed defaults is too risky. But 3.4 is so ancient that none of this may apply. In any case if all else fails you can do it two phases, i.e. get plain C working and to the point where it can link executables and then using that sysroot re-build the compiler with C++ enabled. > (and then I'll > see what work I must do to adapt to the bare-metal > environment). If you are using newlib then you will want to adapt the syscall stubs in libgloss. Brian
