Custom C++ Toolchain

[rbmj]

OK, so a few slight changes to the build process.

headers-build.patch is no longer necessary. Instead, best solution (read: least kludgey) is to manually copy gccdist/WindRiver/vxworks-6.3/target/h to /usr/powerpc-wrs-vxworks/sys-include, and then symlink /usr/powerpc-wrs-vxworks/include to sys-include/wrn/coreip. Yes, this is less kludgey.

Actually all of the patches that are there have been deprecated. The latest GCC incorporates some, and there are others that fix things "better". These haven't been incorporated into mainline yet, but the main issue is that I'm going off to school and won't have internet until late august (no working around this either). So I'm hoping that somebody can make sure that the work is not lost and that these make it in. [1] is approved, but not yet committed, and handles all of the patches to the WRS headers inside of GCC through the fixincludes process. It is a patch series, of which every patch depends on the first in the series. [2] is also approved, but not yet committed, and allows one to force a build of libstdc++-v3 with --enable-libstdc++-v3 passed to configure. A fix for the first gcov issue (obvious) is at [3]. A fix for the second gcov issue (approved, not committed) is at [4]. With those things done correctly, a complete build works.

The other issue is that some of the targets appear to be mis-configuring themselves, as they are allowing implicit declaration of functions in the configure process, which results in bad detection of the target platform's available functions. Hopefully somebody can fix this :-D.

I'm looking for someone to take this over, at least until the regular school year starts, at which point I should be able to maintain everything again (at least for a little while).

[1]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00382.html
[2]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html
[3]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01508.html
[4]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01548.html

I'm going to try and get one of the GCC maintainers to adopt this, but if the conversation doesn't say committed, then it means I wasn't annoying enough.

NOTE: if you look at a patch message and it says a certain file needs to be regenerated, then you'll need to do that otherwise things won't work. The configure files can be regened with autoconf2.64, and the fixincl.x file can be regened by going into the fixincludes directory of gcc and running ./genfixes.