Re: mspg++ and c++ includes

Hi,

I suspect your choice of command line is the issue - there is a
difference between "msp430-gcc" and "msp430-g++".  I am not an expert
here - I've only played around with C++ a little - but my understanding
is that "msp430-gcc" and "msp430-g++" work the same for compiling, but
pick different default libraries when used for the link stage.  If you
want to use the standard C libraries (to get the non-inlined,
non-builtin version of memset, for example, or to get printf), then you
should link with "mps430-gcc" and not use "-nodefaultlibs".  If you need
to link to the c++ libraries - if and when they are available - use
"msp430-g++" (or include them specifically on the command line).

The only thing I am not sure about is when global constructors are
called (before main() starts).  It is possible that the file containing
main() has to be compiled with msp430-g++ to work correctly - I don't
know the details here, but I urge you to check that it is working correctly.

mvh.,

David


On 11/06/13 02:23, Thomas Taranowski wrote:
> Thanks for the comment Paul.  What are you using for your compiler
> flags?  I'm having a couple issues with mine.
> 
> I'm currently using the following:
> -ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -fno-exceptions
> -fno-rtti -fno-enforce-eh-specs -nodefaultlibs
> 
> This works well in with -O2 specified (release build), but fails with
> memset undefined when running my -O0 debug build.  Presumably the
> optimized version is using the built-in library.  Also, I can't seem
> to get printf back in by adding -lgcc -lc.to the linker flags, as I
> think these get ignored after specifying the -nodefaultlibs argument.
> I really want something to just disable the libstdc++ include.
> Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com
> 
> 
> 
> On Mon, Jun 10, 2013 at 5:00 PM, Paul Sokolovsky <[email protected]> wrote:
>> Hello,
>>
>> On Mon, 10 Jun 2013 17:45:00 -0500
>> Peter Bigot <[email protected]> wrote:
>>
>>> C++ is not supported by mspgcc.   Some people are using it to some
>>> degree with some success, and may be able to provide hints about
>>> improved compatibility, but no effort has been made to ensure it
>>> functions.
>>
>> C++ as a language works really well with mspgcc. Well, C++ is big and
>> multi-paradigm, the part which is good for embedded works well (that
>> includes compile-time meta-programming and excludes run-time
>> cycle-burning, like virtual functions).
>>
>> Well, it sucks that things like:
>>
>> =========
>> struct Timer
>> {
>>     const static int irq_no = 10;
>> };
>>
>> interrupt(Timer::irq_no) irq_handler()
>> {
>> }
>> =========
>>
>> don't work, but I put up with that.
>>
>>
>> C++ stdlib is different story. I recently did a survey of MCU C++ libs
>> and found it funny that almost everyone (including me) had circular.hpp
>> or similar in their codebase. So, good-for-embedded things of STL (like,
>> well, template classes) are definitely a miss and people reinvent the
>> wheel. https://github.com/vancegroup/stlport-avr may be a good start to
>> get those.
>>
>>
>>>
>>> It is to be hoped this will be addressed by Red Hat's version.
>>>
>>>
>>> On Mon, Jun 10, 2013 at 5:34 PM, Thomas Taranowski
>>> <[email protected]>wrote:
>>>
>>>> mspg++ seems to be functioning, but all the standard c++ includes
>>>> seen to be missing.  For example, cstdio, cstdlib, etc.  Am I
>>>> missing some part of the install, or is this work yet to be done?
>>>>
>>>> -Tom
>>
>>
>> --
>> Best regards,
>>  Paul                          mailto:[email protected]
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev