[En-Nut-Discussion] C++ Issues

Bob Wirka bobwirka at yahoo.com
Thu Nov 19 05:18:20 CET 2020

Thank you for your reply.
<update to message below>
Well, guess what? Adding #include <cpp/nutcpp.h> at the top of the 'main' file allowed linking with a 'new' class!!!
Delete works. Does derived classes as well.
Don't know yet if this will work in all cases, but it's a start. Will know more tomorrow.
</update to message below>
I'm using Ethernut 4.10.3. Did not get it from SVN.
The compiler is:
> arm-none-eabi-gcc --versionarm-none-eabi-gcc (Sourcery G++ Lite 2010.09-51) 4.5.1
I've included libnutc in the build, but no difference. That file is only 8 bytes; I wonder if there's an error?
I'm not using a makefile; I've created an Eclipse managed project that includes all the needed flags and libraries gleaned from the output of a makefile project.
Compiler flags are: -c -fmessage-length=0 -mcpu=arm7tdmi -mthumb-interwork -fno-exceptions
Linker flags are: -mcpu=arm7tdmi -Tat91sam7x512_rom.ld -Wl,-Map=app.map,--cref,--no-warn-mismatch
g++ is used for compile and link.
I've included a screen shot of the libraries; all are linked except 'libnutcontrib' (which is also 8 bytes).
Works perfectly for 'C' projects...
Thanks again,
Bob Wirka
    On Tuesday, November 10, 2020, 05:23:43 AM CST, Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de> wrote:  
 Bob Wirka writes:
> Hello,I'm able to compile C++, and am able to link an executable for
> the Atmel AT91SAM7X.Am using the Code Sourcery "cs-eabi-lite"
> toolchain. The g++ is  "arm-none-eabi-g++" ,  and -fno-exceptions is
> added to the compiler options.It works, but:
> 1. New and delete result
> in undefined reference errors when linking, even though the compile
> stage is successful.

Ethernut SVN Head or some of the releases?

What gcc?  Recent arm-none-eabi needs -specs=nosys.specs:

commit 14b7df8711df64d254cefaa13969942460cd0821
Author: Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de>
Date:  Thu Oct 1 12:05:24 2020 +0200

    stm32: Nolibc needs nosys.spec for GNU Arm Embedded Toolchain 9-2020-q2-update

diff --git a/nut/conf/tools.nut b/nut/conf/tools.nut
index e2a3755cb..1280f6d02 100644
--- a/nut/conf/tools.nut
+++ b/nut/conf/tools.nut
@@ -170,7 +170,7 @@ nuttools =
            flavor = "boolean",
            exclusivity = toolchain_names,
            file = "include/cfg/arch.h",
-            makedefs = {"TOOLCHAIN=cm3-gcc", "ADDLIBS = -lnutc"}
+            makedefs = {"TOOLCHAIN=cm3-gcc", "ADDLIBS = -lnutc -specs=nosys.specs"}
            brief = "GCC Debug for CortexM (no libc)",
@@ -181,7 +181,7 @@ nuttools =
            flavor = "boolean",
            exclusivity = toolchain_names,
            file = "include/cfg/arch.h",
-            makedefs = {"TOOLCHAIN=cm3-gccdbg", "ADDLIBS = -lnutc"}
+            makedefs = {"TOOLCHAIN=cm3-gccdbg", "ADDLIBS = -lnutc -specs=nosys.specs"}
            brief = "GCC for CortexM (newlib)",

Some experimenting and aquiring knowledge around these issues is

> 2. The toolchain, or standard, include files
> need to be enclosed in "C" {} binding, otherwise undefined
> references appear.A couple of the undefined references are:   
> unwind-arm.c:(.text+0x204): undefined reference to `__exidx_start' 
>   abort.c:(.text+0x10): undefined reference to `_exit'I'm just
> experimenting with C++ compiling here, but would anyone have a
> suggestion as to why this might be happening?

A patch adding the braces is welcome.

Is this against SVN Head? For edix related issues, scan the log of the
stm32 linker files and implement according.

Please rport back!

Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

More information about the En-Nut-Discussion mailing list