Can't get cmath or math.h working

[catsuperberg]

I'm building with c++ main and whenever i use #include to get floating point operations it doesn't compile with error:

fatal error: bits/c++config.h: No such file or directory

From what i can gather it's a linker problem, and by default it doesn't include some parts. I've read that adding -lm flag to linker is the solution, but yaml config only have cFlagsand cxxFlags. I tried both, it doesn't help

EDIT: managed to get it working Solution is really jank, but at least it works for now. I just copied all the files from ..\bmd.stm32-for-vscode\@xpack-dev-tools\arm-none-eabi-gcc\10.3.1-2.3.1\.content\arm-none-eabi\include\c++\10.3.1\arm-none-eabi\bits folder to ..\bmd.stm32-for-vscode\@xpack-dev-tools\arm-none-eabi-gcc\10.3.1-2.3.1\.content\arm-none-eabi\include\bits

[jortbmd]

Hi! Would not recommend the solution you are going for. The math library can be included by adding it to the libraries section of the configuration yaml. e.g.

# libraries to be included. The -l prefix to the library will be automatically added.
# Mind that non standard libraries should have a path to their respective directory.
libraries:
  - c
  - nosys
  - m #this is the library you should include.

Usually this is included but this should fix the issue for you. As this is a configuration issue I am closing this issue for now. However if the issues still persist feel free to open up the issue again.

[catsuperberg]

Hi! Would not recommend the solution you are going for. The math library can be included by adding it to the libraries section of the configuration yaml. e.g.

# libraries to be included. The -l prefix to the library will be automatically added.
# Mind that non standard libraries should have a path to their respective directory.
libraries:
  - c
  - nosys
  - m #this is the library you should include.

Usually this is included but this should fix the issue for you. As this is a configuration issue I am closing this issue for now. However if the issues still persist feel free to open up the issue again.

My config has:

libraries: 
  - c
  - m
  - nosys

But still i had to copy files in bits folder.

[jortbmd]

Could you tell me what functions you are using? And could you share the STM32Make.make makefile you have for your current project?

[catsuperberg]

Here's the make file: https://pastebin.com/9FsBQ7vZ

I use fabsand fmod and use #include <cmath> in header file (my math in separate cpp file with it's own .h file).

[jortbmd]

As far as that can tell that should work. I have made an example project, which does the same thing and prints the number and this seems too compile fine. Could you check if the issues persists if you only include the files in your main.cpp file and do some basic operation there? It might be because of the mix of .c and .cpp files that this is an issue.

[catsuperberg]

Only left main.cpp with #include "cmath" and float testValue = 0.5 * (1 - (float)fabs((float)fmod(50.2 / 60.0, 2) - 1)); in main function. Still same error with bits/c++config.h: No such file or directory.

[leoarcu]

Hey, I had a similar issue. The path to GCC and its libraries was too long and that was causing the problem. Ended up installing VSCode on a different folder and it worked. You can also configure VSCode to install the extensions on a different folder but couldn't get that working.

[jortbmd]

Hi thanks for the input! It seems that this might be related to Windows not allowing paths longer than 260 characters. @KEALHOVIK could you perhaps tell me what the original path length was from your root directory to the library folder? If this is the case I will spend some time in making the installation path of the tooling user selectable.

[catsuperberg]

Full path to ..\bmd.stm32-for-vscode\@xpack-dev-tools\arm-none-eabi-gcc\10.3.1-2.3.1\.content\arm-none-eabi\include\c++\10.3.1\arm-none-eabi\bits seems to be 185 characters

[jortbmd]

I have been testing some more C++ integration this week and I encountered the same problem. It does seemingly have to do with the character limit. Moving the gcc installation somewhere else with a shorter path seemed to fix this issue for me. So it might be worth a try. I will also take this into account and I will check if I can shorten the installation path for the build tools so it will be less likely that this will occur.

[lgacnik]

As a note to anyone who encounters this issue, this doesn't seem to be this extension's problem but rather a fact that using ARM C++ compiler limits you to the so called freestanding implementation. Therefore you may not use most of C++ STL.

And the thing with math.c is that if you call any function from C++ and try building it, the cmath.c file will be automatically included instead. However it seems cmath.c doesn't belong to the freestanding implementation either. Therefore in such case you can choose to modify the standard math file and remove C++ using std::s and cmath.h include. Or maybe a wrapper in C++ that calls C math functions (from a C file).

[yamaan93]

I just wanted to chime in to say I am also having this problem with a fresh project with nothing in it. As soon as I change language to C++ in the yaml file, I can no longer build and get fatal error: bits/c++config.h: No such file or directory 41 | #include <bits/c++config.h> | ^~~~~~~~~~~~~~~~~~ compilation terminated. MAKE.EXE: *** [STM32Make.make:221: build/main.o] Error 1

It's a fresh project without any Cpp files at all, but I was looking eventually to use some cpp.

[jortbmd]

Will check this on a Windows machine. Did you include math.h or any other headers in your project?

[yamaan93]

it seems that the STM32 HAL Drivers include math.h

#ifdef __cplusplus
 extern "C" {
#endif

/* Includes ------------------------------------------------------------------*/
#include "stm32h7xx.h"
#include "Legacy/stm32_hal_legacy.h"
#include <stddef.h>
#include <math.h>

/* Exported types ------------------------------------------------------------*/

fromDrivers\STM32H7xx_HAL_Driver\Inc\stm32h7xx_hal_def.h

[jortbmd]

Finally got around to checking this out. It does seems that this is an issue with the length of the path. I moved the arm-none-eabi folder to my user directory and changed my settings to point to this arm toolchain folder and then it seems to work. @yamaan93 could you verify this? If so I can take it into account for a next release.