Calling so files on sbRIO-9608

[syoshinsya]

We are currently developing the sbRIO-9608 using LabVIEW for Windows.

Although sbRIO runs in a Linux environment, I am using this method because I can run VIs developed in LabVIEW for Windows by connecting and deploying it as an RT target.

However, I am currently unable to call functions in the library function call node for SO files on Linux. The path specified is the path of the SO on sbRIO, and there is no error, but the function is not being called. I thought the VI and SO files must be in the same directory, so I tried to find the location where the VI is stored on sbRIO, but I couldn't find it, and I don't know where the executable will be created once it is deployed.

Is this situation caused by improper path specification?

[rolfk]

You need to read up a bit about ELF libraries and how that specifically works under Linux. Generally if you work under LabVIEW for Linux you can indeed put the .so easily besides the VI's and LabVIEW will be able to reference it and load it as it does so explicitly by its path. But on the realtime targets you have a little problem. There you don't have VIs running in a particular directory that physically exists on the file system.

Instead you have two modes:

- You deploy the VI(s) to the target to run interactive: LabVIEW copies the whole hierarchy into a virtual directory and executes it from there. BUT: as the LabVIEW version doing that is on Windows it does not know and can't deal with ELF shared libraries but instead references DLLs in its Call Library Node. So it won't be able to copy shared libraries to the same location even if you have placed them neatly besides your VIs.

- You deploy your VI's as build .rtexe to the target to run headless. Here pretty much the same applies. The VIs are all inside the virtual file hierarchy in the .rtexe. But LabVIEW can't copy the shared libraries into the rtexe either, as the Linux kernel doesn't know that an rtexe file is some sort of archive.that contains individual files, so could not find the shared library in there.

The by far "easiest" method is to copy the shared library yourself into one of the standard search locations on the target. This would be typically /usr/local/lib/. But you are not done with that yet. You also then need to go to the target and on the command line do a few things:

Open the /etc/ld.so.conf as sudo and make sure the directory where you placed your shared library exists in there. If not add a new line with that directory. Then do a

$sudo ldconfig

This will recreate the dynamic loader cache and if all is well find your shared library and add it to the cache. After that the LabVIEW code on the target will be able to load VIs that reference your shared library.