extcode.h for Linux

[tduffy]

Hello,

I've been rewriting a c library that used the Code Interface Node on Windows to work with the cRIO-9068 running Linux.  The CIN library leveraged a number of NI functions called out in extcode.h.  After doing some digging, I did find the library files that hold those functions - however they all appear to be compiled for Windows and, more specificly, x86.

I've written most of the functions over again, but without knowing everything about how the structs are coming into the library from LabVIEW, i'm getting some odd behavior.

Is it possible there is an equivilent set of libs compiled for Linux ont he ARM architecture?  And if not, does anyone have an example of a lib working in Linux not using the NI functions?

Thanks so much,

-TD

[BradM]

PM sent.

[tduffy]

BradM,

Thank you for your response.  Unfortunitely I think I may have asked my question poorly.

I have existing code that used the Code Interface Node (CIN) to execute C code.  This method of calling C functions has been deprecated.  There are a number of LabVIEW specific functions within the CIN code ( such as DSNewHClr(), DSCheckHandle(), and SetCINArraySize() ).  The prototypes of these functions exist within the extcode.h file that resides in the \National Instruments\LabVIEW 2013\cintools folder.

All of the function prototypes exist within the extcode.h file, however it does not appear (as expected) that the symbols for any of the CIN specific functions exist within the LabVIEW memory space.

It is my understanding that there is no support for the CIN vi within the cRIO-9068.  With that being said, what are the replacement functions that perform these same tasks for the Call Library Function Node, specificly, SetCINArraySize().

There are a large number of functions defined in extcode.h, however none appear to be a 'non-CIN SetArraySize() type function'.

Note: I am using LabVIEW 2013.

Thanks so much,

-TD

[BradM]

http://www.ni.com/example/27159/en/ gives some details on how to resize an array, there are similar documents detailing how to work with LV datatypes from external code.

[rolfk]

In Linux ELF shared libraries you do not need to link in an import object library to access methods in other shared library modules. These functions you are talking about are exported by the LabVIEW kernel lvrt.dll or under Linux lvrt.so for all LabVIEW executables. When you load your own shared library from within a VI, the ELF module loader will automatically search the entire list of already loaded modules for any symbol your library tries to link to and eventually stumble over the lvrt.so exported sysmbols and link to them.

Basically you compile your shared library with the extcode.h file (and optionally the hosttype.h file if you intend to make use of OS API functions too) and then link it into the desired shared library module and then simply call that shared library module from a Call Library Node. The ELF module loader will make sure that all the symbols that your shared library wants to import will be resolved automatically, first by searching the loaded modules in the current process and then by searching for .so modules in the well known OS locations on disk. Only when all that fails will you get an error on loading of the shared library. You do of course have to make sure to use the correct ABI mode when compiling and linking your shared library and that is because of the ARM CPU on the Linux RT target different than for other LabVIEW Linux systems, but that is basically all resolved in the makefile for your shared library module and should not have any influence on the C source code itself.

The shared library interface on Windows works very differently and there you either need to load external symbols explicitedly or link your object module with an import library for the external symbols you are using in your code (and an import library is really just a call to LoadLibrary() and a bunch of GetProcAddress() calls itself, but needs to be linked into the shared library as the import and export tables for the Windows PE format are not as powerful as for the ELF format, and would not allow Windows to magically resolve all external symbols properly in all cases.

[tduffy]

rolfk,

Thank you for taking the time for coming up to speed on the thread, and your detailed response - your write up will be a great resource for those who are confused to the difference between shared libraries in Linux and Dynamic Link Libraries in Windows.

"""

When you load your own shared library from within a VI, the ELF module loader will automatically search the entire list of already loaded modules for any symbol your library tries to link to and eventually stumble over the lvrt.so exported symbols and link to them.

"""

It appears that is correct for the version of LabVIEW RT running on the cRIO-9068.  Unfortunately, it appears that NI did not implement all functions that exist within the CIN tools on 2012.  Specifically I can call out SetCINArraySize() either does not exist within the real-time function list, or is not being loaded into the symbol table.  There are a number of other functions within the CIN tools that *are* implemented, which is a bit odd.  I have not run through the entire list of functions within the extcode.h file, but not all of them exist within the LabVIEW RT enviornment on the cRIO-9068 under LabVIEW 2013.

Thank you again for your response!

-TD

[rolfk]

SetCINArraySize() as its name implies only has a meaning for CINs. It is not implemented in the LabVIEW kernel but in the special lvsb.lib/lvsb.o link library that you had to link with CINs.

A shared library has no way of knowing the actual datatype of a paramater implicitedly and even linking lvsb.lib (or under Linux lvsb.o) with your shared library won't work as this is a feature of the CIN architecture which also receives a complete list of dataype informations for the entire parameter list. The correct way in shared libraries to deal with array parameters would be to use the NumericArrayResize() function and knowing the actual type of your array elements at coding time. If your array is a complex array, meaning an array of clusters, then you are in a bit of a problem here, because NumericArrayResize() only allows specifying a skalar array element type.

[BradM]

You could use tools like nm or readelf (installable through the external repositories) to check to see what symbols are exported or not.