0
0

This question is being submitted on behalf of jshi:

I am hitting a wall when it comes to using C++. I was confirmed that cFE is compatible with C++. However, the cFE include files are not properly liked with the g++ compiler. The gcc compilers all have -I/(include file path). g++ compilers have nothing. Once I fixed that (by adding a .cpp.o rule in the .mak file in cFE), I run into problems with unable to find entry point to SAMPLE_AppMain.

Is the runtime environment set up to run C++?

  • You must to post comments
1
0

Use the gcc compiler, not g++.  gcc will compile your .c files as C, and your .cpp files as C++.  g++ will compiles all files, including .c files, as C++.  There are slight differences in syntax, i.e. typedef, that will cause g++ to error when it tries to compile the .c files as C++.  Also, the answer above has some typos.  You can either put this at the top of all the CFS libraries (which I hope they eventually will be):

#ifdef __cplusplus

extern “C” {

#endif

and this at the bottom:

#ifdef __cplus

}

#endif

Or, you can just wrap each of your #include <cfe.h> with that extern “C” directive in your own code.

What that does is tells a C++ compiler (when included from a .cpp file) to use C style linkage and not mangle the names.  Use the #ifdef __cplusplus if you put it in the cfs headers because the C compile will error when it hits the extern “C”.  The ifdef makes it ignore it, which it should since its already C style linkage anyway.

Another pointer.  Make sure you use C style linkage for all your callbacks and your application entry point.  I recommend writing a C function wrapped in an extern “C”, which instantiates your C++ object and calls its entry point.  If you have any table validation functions, an application termination functions, or your register any interrupt handlers, those all need to be C style linkages.

Lastly, make sure any constructors for globals or statics are called on module load.  Some platforms, i.e. VxWorks 6.7, require an additional build step to make that happen.  Some platforms require additional decorations.  Without these, things behave funky.  I can tell you that the linux toolchain does this automatically so the POSIX OSAL works with C++ just fine.

  • You must to post comments
0
0

Answering on behalf of cfs-community list:

I was inexperienced with c/c++ mixing with different compilers.

Turns out just minor tweaks were needed. The c++ make rule I added in ./mission/cfe/fsw/cfe-core/src/make/app-rule.mak, .cpp.o, need to use gcc not g++ because cFE use gcc and the gcc linker can’t link to g++ objects. The new gcc rule linked to the c++ library with -lstdc++ and was able to compile cFE linkable object files.

all functions in app.h is wrapped with:

#ifdef __cplusplu

#incldue <c++lib_of_some_kind>

extern “C” {

#endif

I was not familiar with the gcc linker and cFE compiler settings. Just a couple lines of makefile edits fixed it. I would recommend the addition of this make rule (even in documentation) in app-rules.mak for future releases so c++ src can be naturally compiled without digging for cFE compile rules. Just so that people know cFE only interface with c functions, reminding people to use extern “C” could be helpful.

Thanks to everyone for helping!

On Monday, November 14, 2016, glimes wrote:

Also need to assure that the appropriate C++ runtime library
is linked into the core — but I think this would have caused
problems earlier than failure to find AppMain, so you may
already have fixed this.

On Monday, November 14, 2016, cmonaco wrote:

We have some experience compiling cFE w/ C++ compiler and integrating with C++ applications for our testbeds.  The person here that knows the most about it says “Probably just didn’t declare the SAMPLE_AppMain function as extern “C” so the name got mangled.”

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.