I am using GNUARM 4.3.2 with Eclipse ARM Plugin. Free RTOS code fails to compile Does anyone know of some sort of a GCC compile flag to turn off this type of strict checking of data type and pointer type conversion? All the errors are related to assignment operator with type conversion:

arm-elf-g++ -Os -Wall -c -fmessage-length=0 -MMD -MP -MF"FreeRTOS/queue.d" -MT"FreeRTOS/queue.d" -mcpu=arm7tdmi -o"FreeRTOS/queue.o" "../FreeRTOS/queue.c"
../FreeRTOS/queue.c: In function 'long int xQueueGenericReceive(xQUEUE*, void*, portTickType, long int)':
../FreeRTOS/queue.c:856: error: invalid conversion from 'void*' to 'signed char*'
../FreeRTOS/queue.c:935: error: invalid conversion from 'void*' to 'void**'
../FreeRTOS/queue.c:935: error: initializing argument 1 of 'void vTaskPriorityInherit(void**)'
../FreeRTOS/queue.c: In function 'void prvCopyDataToQueue(xQUEUE*, const void*, long int)':
../FreeRTOS/queue.c:1058: error: invalid conversion from 'void*' to 'void**'
../FreeRTOS/queue.c:1058: error: initializing argument 1 of 'void vTaskPriorityDisinherit(void**)'

I tried to fix each error manually, however, those more errors appear and I don't want to fix all errors manually in case I want to upgrade the source code of FreeRTOS later. The same FreeRTOS code compiles just fine in Windows Visual Studio.

Preet

Sounds like it is compiling the program as a C++ program instead of a C program. C++ does not allow void* to convert to other types automatically like C does.

Yes, I'm using g++ as compiler since I want to compile for C++on purpose. Any easy way to resolve this, such as adding a compiler option to over-ride this type of C++ Checking?

Preet

FreeRTOS should be compatible with a C++ build provided you build the FreeRTOS files themselves as C files. They already contain extern "C" statements. Alternatively edit the code to remove the data hiding.

As davedoors said, FreeRTOS is set up to be compiled as a C program, and is defined in a way that is can link to a C++ program without problems, as the headers are set up to handle that. It would be significant work to edit the files to let FreeRTOS to compile as a C++ program (and these mods would need to be redone on each new release).

The significant issues that need to be handled are that the type for pointers to the various structures that FreeRTOS uses are declared for user code to be void* but pointer to the appropriate structures in FreeRTOS code. This will cause linking errors if the FreeRTOS files are complied as C++ as the user will call a version using void* parameters, while the definition will be with struct xxx* parameters and not match up. I did ask Richard awhile back why he used void* instead of struct xxx*, with xxx being an incomplete type, as allowed by the C standard, and the reason was that for some of the targeted machines, the major available compiler didn't support that feature.

I have been meaning to ask Richard if he would be interested in a submission that would make a (simple) structural change that would allow ports to indicate if they support the incomplete type construct, and if so, use it to better type check parameters, this could also make it simpler to compile with C++ as all C++ compilers will support the incomplete type construct and at least most of the void* would go away (one place I can think of is the task parameter, as FreeRTOS does not know what it points to).

I fiddled with this a lot today and came to a conclusion that Eclipse ARM Plugin has a bug. I was able to select in the eclipse IDE which folders to use gcc and which folders to use g++, however, somehow it adds -mthumb flag to the folders being compiled with gcc, which kinda breaks apart the whole thing.
I guess the solution to this problem is either go through to fix all the FreeRTOS and typecast each error statement or stick with C compiler. The reason why i wanted C++ is because I wanted my students to be able to have the option about how they compile. I also have to stick with Eclipse IDE since most students do not know about makefiles and building their own set will steal a few weeks of the semester.

I guess, I will go ahead and try to fix error-by-error, see how far I get, and make one template for FreeRTOS C++ Project that everyone can use.

Preet