We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎10-10-2018

Tips for SDK C++ projects using C source files

Something in the default behavior of the SDK's code editor was confusing me, and it took a couple of days of investigation for me to understand what was going on and what to do about it.  I will share my findings because I am pretty sure others will struggle with this.  
To be clear, I am using the SDK's IDE to create and manage my projects and associated make/build files.
- SDK 2018.2 on Windows10-x64
- Zynq 7020 and 1 GB DDR
- FreeRTOS 10 with static allocation enabled
- Target application specified as C++ in SDK
- Using SDK to manage project configurations and also the make/build process
Background info:
1. Applications created as C++ in the SDK will use g++ compiler, which treats all sources as C++.
2. FreeRTOS library is compiled purely as C
3. FreeRTOS, when configured to allow static allocation (of task stacks, etc.), requires application to provide implementation of two functions: vApplicationGetTimerTaskMemory, vApplicationGetIdleTaskMemory
Because of all of the above, if I wish to place my implementations of vApplicationGetTimerTaskMemory,
vApplicationGetIdleTaskMemory in a .c file (which makes sense because they are really part of FreeRTOS), it is going to be compiled as C++ by default.  That is okay if I wrap them in extern "C".
Doing so will build, but the code editor perceives the presence of extern "C" as a syntax error and the entire block of code that it encloses is highlighted with orange underlines - very ugly.
I would expect that the environment would be fully consistent in treating .c files as C++, but code editor does not do this by default.
Here are some workarounds for this, each of which has varying tradeoffs.
1. Change "Language Mappings" (accessed in Properties dialog, C/C++ General) at top level of project so that C source files are treated by code editor as "GNU C++". They are already being treated a C++ for compilation purposes.
Pros: extern "C" can be used in .c file and looks okay in code editor
Cons: All .c files in project still will be compiled as C++
2. Change "Language Mappings" on a per-file, as-needed basis (Properties dialog of each specific file)
Pros and cons same as for workaround #1
3. Add -x c to the compiler flags for individual .c files which you wish to be compiled as C.  Leave the Language Mappings for .c files as the default of being treated in code editor as C files.
Pros: The C files you modify in this way look and build like proper C files
Cons: You may end up with a mix of how .c files are treated in the project, creating a major risk of regressions and developer confusions over time
4. For groupings of many C files, e.g. some third-party code, consider a separate library project. 
When just a few .c files are to be treated one way or the other, right-clicking and changing settings is acceptable. But when there are quite a few .c files which don't do well being compiled as C++, as with the BSP, organizing these as a separate library might be the way to go. Wrap header things, as appropriate, in #ifdef __cplusplus  extern "C" {  and so forth.
Pros: More control over building these true to their "C" nature, better isolation and interface.
Cons: Time invested to create and maintain a separate project for the library
Tags (3)
3 Replies
Registered: ‎10-06-2016

Re: Tips for SDK C++ projects using C source files

Hi @jsam062,

Thanks for sharing this content with the community! I'm sure it might be useful for others.


Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Registered: ‎03-27-2019

Re: Tips for SDK C++ projects using C source files

Do you have any idea in the case of c-compiled .so libraries which are being called from .h headers surrounded by the #ifdef __cplusplus extern "C"  included in the actual C++ main program?

If I use a C main program calling the c-compiled libraries, the program works but when using a simple c++ program calling the C-compiled libraries, they return failed, and the thing is that I do  not want to implement <vector>, <boost_options> and some other functions in c. any idea about .so libraries which are linked at the application startup?  Not sure if I need to twick something in SDK project properties to make it work.



0 Kudos
Registered: ‎03-27-2019

Re: Tips for SDK C++ projects using C source files

I finally managed to make it work.

My final goal was using C-compiled code (RFDC drivers for the ZCU111 board) and add the functionality like c++ vectors along with some other c++ cool stuff like boost  libraries.


Firs of all, because I am using RFDC drivers compiled in C, I decided to use C in XSDK and invoking C++ .hpp and cpp code within my main program like “cpp_header.hpp”. This header is language mapped with C++ in source file properties, like it is explained in this forum.  However, because I am using C language I had  to do few things:

  1. For the header .hpp, wrap my c++ functions prototypes in #ifdef extern C { etc., etc. I did not use any C++ libraries here.
  2. In the .cpp file I add the c++ libraries and define my c++ functions.
  3. Define in path and symbols file properties the symbol __cplusplus with any value, it can be 1.
  4. You need to set your toolchain in toolchain editor for the cpp file using ARM V8 linux g++ compiler. First, I tried gcc compiler but it gave me linker errors, in stackoverflow they suggested use the g++ linker as it has more functionality when linking libraries automatically so…
  5. In the PROJECT properties, not the file, go to settings linker command, and change gcc part for g++.


Hopefully, this will help you to use in XSDK the ability to wrap c++ code using C compiler for the whole project and for those c++ files the g++ compiler.

0 Kudos