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 <pmis...@gmail.com> wrote:
>> Hello,
>>
>> On Mon, 10 Jun 2013 17:45:00 -0500
>> Peter Bigot <big...@acm.org> 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
>>> <t...@baringforge.com>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:pmis...@gmail.com
>
> ------------------------------------------------------------------------------
> 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
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
