ESP32 Forum

I am attempting to port some C++ code and test cases onto the ESP32.
The first error is 'to_string' is not a member of 'std'
A fix is described here: https://stackoverflow.com/questions/129 ... ys-g-mingw
EDIT: although I cannot find the relevant include directory.

I am also getting:
2) 'stack_t' does not name a type
3) 'MINSIGSTKSZ' was not declared in this scope
4) error: 'SA_ONSTACK' was not declared in this scope
5) error: no matching function for call to 'sigaction::sigaction(int&, sigaction*, sigaction*)
etc

So a few POSIX style issues.

Is there a better/more up to date MINGW which I can use with the IDF?
Applying patch after patch is ok until something breaks! Better to get an up to date version.

Hi PeterR,

Is the code failing to compile for ESP32 or for Windows?

Mingw is a Windows unix layer applied at compile time so you can build "native" Win32 apps using *nix APIs. The ESP32 toolchain for Windows is built using Mingw (to run on the host), but it's a cross-toolchain targeting the ESP32 so the toolchain libraries for ESP32 are not Mingw libraries, they're "bare metal" newlib & GNU libstdc++.

The first error is 'to_string' is not a member of 'std'

I was able to compile the following code under IDF with no problems:
Is it possible the "#include <string>" line is missing in the code you are compiling? The same error you have will appear if the include line is missing (underlying reason: including the header is what adds 'to_string' to the 'std' namespace).

It's hard to say without more details, but if you're porting code that requires some configuration step which ESP-IDF can't run then it's possible there are some generated config headers which the code expects, but which aren't including all the system-level headers you need. Some manual tweaking of this header may be required.

2) 'stack_t' does not name a type
3) 'MINSIGSTKSZ' was not declared in this scope
4) error: 'SA_ONSTACK' was not declared in this scope
5) error: no matching function for call to 'sigaction::sigaction(int&, sigaction*, sigaction*)

These are defined in sys/signal.h and you can #include <signal.h> for the compile to succeed. I am guessing this is the same missing config-generated header problem mentioned above, because signal.h is the standard header name where these things are usually defined.

However, it's a little more tricky than this: ESP-IDF has no POSIX signal processing subsystem (FreeRTOS tasks don't translate cleanly to the concept of POSIX processes so signals don't make a lot of sense). This means code which uses POSIX signals will need to be rewritten. Even if the code compiles it will fail at the linker stage as our C library has no signal-related functions to link against.

Thanks.

The build fails to compile for the ESP32 (make -j8 flash). Visual Studio 2017 compiles and runs fine but then VS would probably accept Cobol as C++.
Doesn't compile for me. Weird.

POSIX
https://github.com/catchorg/Catch2/blob ... ion.md#top shows me how to disable signals and also work around std::to_string(0)
I can now cross compile but:
(my compile switches are: CPPFLAGS := -fexceptions -frtti -fpermissive)
etc.

Clean, enable exceptions in menuconfig and build allows application to link.

Now regular debugging, panics & stack overflows.
Will post a summary of how to get Catch2 running when done. Catch2 is a lot easier to write tests for than Unity (IMHO) and supports C++ tests.

Catch2 works fine on the ESP32 with a couple of tweaks.
Catch2 is probably the easiest test framework to get started on & I would recommend.

1) Add the following compile options to each file: 2) Use the CATCH_CONFIG_RUNNER option
This is described in the documentation https://github.com/catchorg/Catch2/blob ... wn-main.md
The Catch code is added to your app_main()

3) Bump the main task's stack
menuconfig, splash out.

4) Trick the build into keeping tests contained in separate compilation units
The default build mechanism will drop TEST_CASE() definitions contained in compilation units other than main.
You can force the build to keep the tests by adding a function to each compilation unit and calling from main.
The function does not need to do anything.

I will have to research build settings later...

Hi PeterR,

Glad you got Catch2 working smoothly!

PeterR wrote: ↑

Thu Apr 25, 2019 11:11 am

Code: Select all

std::to_string(0)

Doesn't compile for me. Weird.

Sorry, I forgot that I was using our gcc 8 preview toolchain. std::to_string() was a known issue on the gcc 5 toolchain, sorry for misleading you. There is a workaround mentioned in the GitHub issue comments, but updating to gcc 8 may be the best solution if you want to re-add this functionality.

PeterR wrote: ↑

Thu Apr 25, 2019 11:11 am

4) Trick the build into keeping tests contained in separate compilation units
The default build mechanism will drop TEST_CASE() definitions contained in compilation units other than main.
You can force the build to keep the tests by adding a function to each compilation unit and calling from main.
The function does not need to do anything.

I will have to research build settings later...

ESP-IDF links all components as libraries, so you have to give the linker a reason to look in a given object file or it won't ever be added to the final binary. Adding a function and calling it is one way to do this.

Adding a dummy symbol as a "linker hook" and referencing it with "-u linker_hook_name" in the linker flags is another way. You'll find a lot of IDF components do this, ie https://github.com/espressif/esp-idf/bl ... nent.mk#L8

The "unit test" support in IDF passes some linker flags around the "test component" libraries so that all object files are linked into the final binary, regardless. This behaviour is quite tightly coupled with Unity and the unit-test-app but it may be possible to leverage it into a different app.

(my compile switches are: CPPFLAGS := -fexceptions -frtti -fpermissive)

I'm surprised -frtti works as I didn't think we had a libstdc++ compiled with RTTI support. I guess there's enough support for whatever Catch2 is using - good news!

Thanks.

I'm surprised -frtti works as I didn't think we had a libstdc++ compiled with RTTI support. I guess there's enough support for whatever Catch2 is using - good news!

The use case was a type safe boost::any (BTW: in specreg.h 'PS' conflicts with Boost)

You are right. I had my UUT as -frtti whilst the Catch2 & test cases were -no-rtti
This allowed me to compile and link but I was throwing when comparing type_index() values.
On the other hand if I -frtti Catch2 stuff then I end up with: Which fits your libstdc++ statement.

As it stands I will need to remove type safety which is a shame.
Any ideas?

How do I build libstdc++ with -frtti?

PS This is not a Catch2 problem, it is that my use/case is not supported by libstdc++.

Going to add boost typeid when I have time.

PeterR wrote: ↑

Fri Apr 26, 2019 12:53 pm

How do I build libstdc++ with -frtti?

I'll check with the tools team, but I think this is a non-trivial amount of work (and increase in binary size) which is why it's not supported.

EDIT: Tools team is looking into this. Please subscribe to this GitHub issue if you'd like to be updated with any progress: https://github.com/espressif/esp-idf/issues/1684

Thanks.
I loaded Boost type_id which is trivial to get working.

We're lucky to have C++11 on an embedded platform so I will keep with boost for portability sake.
You may stand down if I'm the only one interested in RTTI.

BTW: I would rather time were spent improving amount of IRAM available e.g. build option to disable FLASH write.