We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Building new firmware application using RTX Kernel and stm32f10x_lib.h generates error because library is not C++ compatible.
Development Board: STM3210E-EVAL OS: RTX Kernel Tools: uVision4
After creating a new uVision project for the STM3210E-EVAL board and a basic startup.cpp file a new compile-able project exits. Next, attempting to use the Keil STMicroelectronics include file and libraries causes compile errors. By specifiying the following in the startup.cpp file: “#include <stm32f10x_lib.h>” errors occur. They are:
C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h(55): error: #65: expected a ";" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: typedef enum {FALSE = 0, TRUE = !FALSE} bool; C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h(55): warning: #64-D: declaration does not declare anything C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: typedef enum {FALSE = 0, TRUE = !FALSE} bool; C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_type.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(401): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::CPUID" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(467): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESPCMD" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP1" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP2" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP3" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::RESP4" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::DCOUNT" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::STA" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::FIFOCNT" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h(515): warning: #368-D: class "<unnamed>" defines no constructor to initialize the following: C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: const member "<unnamed>::CALIB" C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: { C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: ^ C:\Keil\ARM\INC\ST\STM32F10x\stm32f10x_map.h: startup.cpp: 4 warnings, 1 error
Why are the libraries and header file not C++ compatible. It is only natural to assume that someone would use RTX Kernel and C++ files.
My apologies if I have remembered that wrongly. I just know that every time I reinstall the Keil distributed MDK, RTL and ST libraries, I have to fix the bool thing and fix this "new" problem. I always just change "new" to "newname", so I searched for "newname" in my current installation and that's where I found it.
When I have a moment, or the next time I have to fix this, I'll clarify.
CH ==
Found it. It's in file_config.h:
extern BOOL fat_rename (const char *old, const char *new, IOB *fcb);
Apologies again for my slightly flaky memory. I don't know if the filesystem library claims any specific C++ compatibility to be fair, but I have not had any problems using it from C++ having changed this line, and having dealt with the usual extern "C" business.
Any clarification of the situation would be welcome.
Yes, that was true for older RLARM versions. In RLARM v4.05 this mistake has been corrected.
http://www.keil.com/update/rl-arm.asp
So it has. Thank you. In this case, could I put in a plea for the function prototypes to be surrounded in
#ifdef __cplusplus extern "C" { #endif // prototypes of functions with C linkage #ifdef __cplusplus } #endif
as has been done in RTL.h. Saves me having to do
extern "C" { #include "blob.h" }
around every #include that might itself #include "file_config.h" after an indefinite number of levels of nesting.