header file format, shared libraries and labview

[buckleyalex]

Hello

I am currently tring to build a wrapper for UHD in Labview and access it as shared library.

I have run into a problem with using the sharded libary wizard that builds vi's for my functions. Along with the library.so, Labview requests the location of header files.

It also wants the header files for all included routines, say stdio.h

So to perform some string operations I had to provide the location of all the standard headers (/usr/include).

Now that I have the structure of what I want  built up I am inlcuding a call to a fucntion from UHD. SO therefore I am going to have to provide the location of those headers (/usr/local/include/uhd).

My problem is that the file extensions are .hpp not .h

Is this a dead end? Is there no way for Labview to read a header file with any extensionother than .h? I could attempt to carpet bomb the UHD with grep and sed to change all ocurrences of h. with .hpp, but UHD includes boost, which to my understanding requires .hpp. 

Alex

[JamesKent]

Hi BuckleyAlex,

Unfortunately Boost will need to use .hpp files as those are C++ headers, and C++ only, and Boost is a library available for the C++ language. Unfortunately as you found the shared library wizard will only look for .h files, which are both C/C++ compatible, and my reccomendation is for you to find equivalent .h files for these library functions. The call library nodes that are used can only use standard C interfaces, and therefore you will need to build your interface to use standard C calling conventions. 

I've personally used extern "C" in the past to allow me to link to C++ code, as it defines the interface in C so the C++ compiler does not mangle it.

Best Regards,

[buckleyalex]

Hi James

Thank you for your response.

I had actually built up a wrapper properly exposing only extern "C" calls in a .h file.

What was happening was that every time I use the library import wizard and select update exisiting library after making changes, it always produces an error report saying it is unable to create vi's. Even if there really exists no error. Furthmore the changes are not made to the workspace, the project must be closed and opend to for the changes to take places.

This eroneous error report was very missleading.

Alex