LabView Linux RT C++ .so example

[jhu003]

The provided NI example shows how to build a .so from .c file (C code).

https://nilrt-docs.ni.com/cross_compile/build_shared_library.html

I've worked through the example but have trouble when trying to do the same thing for a C++ (.cpp) file.

Anyone have an example of a C++ shared object for use on a LabView Linux RT target. (PXI in this case)

Thanks!

[rolfk]

What is your problem? It doesn’t work is rather broad:

- you can’t compile or link the so file?

- the Call Library node doesn’t let you select a function in the so?

- LabVIEW gives you an error when you close the CLN configuration dialog, telling you that the shared library or one of its dependencies couldn’t be loaded?

- you can configure and run the CLN but when you execute it it produces gibberish?

- other, such as exploding computer or attack by monsters?

Each of these is “doesn’t work” but the possible problems and according solutions are very different!

[jhu003]

I can compile C code and C++ code with no issues; however, when placing the C++ version of .so on the Linux, the function name is always mangled and cannot be called. 

Using extern "C" in the code doesn't fix the issues.

I'm just looking for one example of C++ code and a header file that compiles into a .so that can be called from Call Library Node. 

So far I can only find C examples.

Thanks

[rolfk]

Something is wrong.

extern "C" is the thing that should prevent name mangling. How do you declare the function prototype for the functions you try to export?

class Base
{
public:
    virtual void Foo() = 0;
};

class Derived : public Base
{
public:
    virtual void Foo() {};
};

extern "C" Base *MyExportedFunc()
{
    Base *pb = new Derived();
    return pb;
}

For at least Microsoft C it is sufficient to add the extern "C" to the function declaration in the header file. No need to repeat it in the function implementation in the cpp file.

[jhu003]

I figured it out at least in Visual Code (windows) cross compiling for Linux Target.

The header file needs the extension .hh not .h and c++ code file needs the extension .cpp

Of course extern "C" now works as advertised.

Thanks! 

[rolfk]

Thanks for the feedback. The *.hh thing really feels murky. The *.cpp is standard for GCC. The GCC wrapper uses the file ending to decide if it needs to invoke the actual C or C++ backend unless you specify the backend to use in the command line options. Microsoft C does something similar.

Things of course get even murkier if you use other toolchains. Some demand C++ header files to be *.hpp, simply because "why not?". Some embedded toolchains have a knack for *.cc files, again "why not?".