C++ support added to newt

[Sterling Hughes <st...@apache.org>]

Hi,

I\u2019ve added C++ support to Newt in the \u201cdevelop\u201d branch.

In order to use C++ with newt, the compiler definition files have a new 
entry which is:

compiler.path.cpp: arm-none-eabi-g++ -x c++

And newt will search every package for files that end with *.cpp, *.cxx, 
and *.cc.  I decided not to compile *.C, because I think the case 
insensitivity is a good enough reason not to :-)

In order to use the vast majority of C++ standard libraries, you must 
compile your project without using baselibc, which is not compatible 
with C++.  This will increase code size on your project.  By default, 
we\u2019ve included baselibc as a dependency in most of the BSPs, as it is 
significantly smaller than newlib.  Removing this dependency will remove 
baselibc, and allow you to natively use the C++ standard libraries.

Note: I\u2019ve added a directive to the linker:

compiler.ld.flags: -static -specs=nosys.specs -lgcc -Wl,--gc-sections

-specs=nosys.specs automatically generates weak symbols for the standard 
libc stubs (i.e. _close, _exit, etc.)

In the case of compiling with newlib, _exit was not being resolved from 
libc_stubs.c in the BSP.  I believe this has to do with link stage, and 
adding -specs=nosys.specs does the right thing: but I have not tested 
this.

In general, we should probably look to trim down libc_stubs.c.  With 
this new compiler option, I can completely eliminate this file on the 
NRF52DK BSP.  Ironically, _exit is the only libc stub we actually 
override with anything useful :-)  But I\u2019d be interested in folks 
thoughts here, perhaps we want to keep libc_stubs around for when we 
support other compilers.

sterling

Re: C++ support added to newt

[Sterling Hughes <st...@apache.org>]

> In the case of compiling with newlib, _exit was not being resolved 
> from libc_stubs.c in the BSP.  I believe this has to do with link 
> stage, and adding -specs=nosys.specs does the right thing: but I have 
> not tested this.
>
> In general, we should probably look to trim down libc_stubs.c.  With 
> this new compiler option, I can completely eliminate this file on the 
> NRF52DK BSP.  Ironically, _exit is the only libc stub we actually 
> override with anything useful :-)  But I\u2019d be interested in folks 
> thoughts here, perhaps we want to keep libc_stubs around for when we 
> support other compilers.
>

I have tested that _exit gets properly resolved, and removed 
libc_stubs.c from all of the BSPs.  They now get libc stubs from GCC, 
and _exit is defined in a new file, hal_common.c to call system_reset().

Sterling