[En-Nut-Discussion] C++ Issues

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


 Uwe,
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
needed.

> 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!

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

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion  


More information about the En-Nut-Discussion mailing list