ESP32 Forum

Strange.
The small worked example builds & links with or without -frtti in Makefile.
I had previously looked at -frtti and also -fexceptions (I believe that also enables -frtti) & had made changes so I am not sure which build was the failing build last week

Today: The example builds with a default Makefile & sdkconfig where C++ exceptions and enable C++ run time type are disabled.
Also builds with Makefile containing -frtti & sdkconfig where C++ exceptions and enable C++ run time type are disabled.

I don't think I have seen the last of this.

Strange.
The small worked example builds & links with or without -frtti in Makefile.
I had previously looked at -frtti and also -fexceptions (I believe that also enables -frtti) & had made changes so I am not sure which build was the failing build last week

Today: The example builds with a default Makefile & sdkconfig where C++ exceptions and enable C++ run time type are disabled.
Also builds with Makefile containing -frtti & sdkconfig where C++ exceptions and enable C++ run time type are disabled.

Sorry if I didn't explain this clearly before:

Your project Makefile should not need not need to set -frtti or -fexceptions at all, the IDF build system should be setting these variables where they're needed automatically based on the project config.

If you needed to put these values into a Makefile for the project to build successfully, the most likely root cause is that something else is cloberring IDF's compiler flags and replacing them with their own. This could be the project Makefile, a component.mk file, a component Makefile.projbuild, or a system environment variable. Generally this is a bad thing and is not what you want, unless you're really sure about overriding some core part of IDF - there are different variables you can set which append to the command line, rather than replacing it.

If none of the build files are setting these variables, maybe a stray system environment variable is to blame?

Hi,
My appologies for not responding earlier.
You are correct w.r.t. the new build system however the stable 3.3.1 tool, IDF 4.0 build allows menuconfig of exceptions but not rtti. I would love to know how to add project CPPFLAGS as then I could switch betweeen old/new emerging builds easily. I did remove makefile -frtti without resolution.
I have had to push this ehancement/issue into the next release which we will start in a week or two. IMHO there is some CMake weirdness (as per my other posts) which I need to work through. Hopefully just documentation clarity.

You are correct w.r.t. the new build system however the stable 3.3.1 tool, IDF 4.0 build allows menuconfig of exceptions but not rtti. I would love to know how to add project CPPFLAGS as then I could switch betweeen old/new emerging builds easily. I did remove makefile -frtti without resolution.

Ah, OK. I'm not sure I understand but possibly I do. This was the sequence of events?

• In ESP-IDF v3.3.x you manually added -frtti to compiler flags in a project Makefile causing RTTI to be generated by g++ at compile time.
• When you updated the project to ESP-IDF v4.1 the new config option caused -fno-rtti to be added to the compiler and linker flags by the internal build system automatically.
• Therefore some files were being compiled with -frrti but linked with -fno-rtti, causing linker errors due to the mismatch.

The gcc5 toolchain in v3.3.x doesn't come with a libstdc++ that has RTTI enabled to my knowledge, so I'm surprised that step 1 worked at all. RTTI in v3.3.x is not supported, but great to hear it worked somehow.

If you want to keep this up then you can do something like this to only add this flag on v3.3.x:
https://esp32.com/viewtopic.php?f=13&t= ... 140#p54140

... but bear in mind there are almost certainly some libstdc++ RTTI operations that won't work on v3.3.x.