Call Function Library doesn't found .so File in the cRIO memory

[Domodo]

Good morning,

I'm trying to open a .so file stored in the cRIO 9058 memory using the call function library node. I got always the same error (if I specify the path on the block diagram), "LabVIEW: (Hex 0x7) File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.". I'm using linux 21.5 OS and labview 2021 SP1 32bit. The .so file was produced using "C & C++ Developement Tools for NI Linux-RealTime 2017, Eclipse Edition". If I try to insert the file path directly in the node, by clicking on apply LV starts to search in the host memory and not in the target one. Following  I uploaded 3 images: ---TrialPath.jpg - shows the path in which the file was stored ---LV_BD&FP.png - shows the execution of the call library fuction node in LabVIEW, with also the "Check if File or Folder Exists.vi" which confirm that the path is corrected, and the file exist. ---ExecutionFileSOusingPutty.jpg - shows that the file is executable in linux OS, using putty. The attached zip contain the used project and the workspace project used in eclipse to generate the .so file.

Thanks in advance for your help.

[rolfk]

A LabVIEW real-time program under NI Linux RT usually executes as lvuser. Access to the admin home directory from within a LabVIEW program is at least suspicious. There might be additional issues that may allow to stat the file in the admin directory (stat is the command to query properties of a file and requires less access rights than to open the file and especially load it into executable memory).

Also, is your library self contained or does it call some other functions from a different library? This library may not be available on your system, not in the right version as compiled for in the gcc toolchain used in the NI Linux-RealTime 2017, Eclipse Edition or it may be not installed in an accessible location.

[Domodo]

I tried also by inserting the file in the "lvuser" folder but nothing change. The file was uploaded on the target using Eclipse and giving it all the permissions (look at the FilePermission image).

The library contain only one function that doesn't call other one (the image Code contain the code inserted to create the library).

[rolfk]

That is a main() function and will create an executable! You can not interface an executable as shared library, since it does not export any functions to link to, no matter how much you change its name by appending .so to the file name!

That was actually my next question because in the images you showed calling the file (without .so extension) as executable from the command line but then try to call it as shared library in LabVIEW.

[Domodo]

You are right about the main function, but also changing the name of the function (by removing the main) nothing change.

I think that you are refering to the image "Code" when you saied that I showed the file without .so extension. That image showd the .c file used in eclipse to generete the .so file using the gcc configuration based on the used target.

Anyway you can see all the files in the uploaded zip (BlankPrj).

[rolfk]

You need to change the compile and link flags in the project settings to create a shared library. The executable format of a shared library is not the same as for an executable!

And I was refering to ExcecutionFileSOinPutty.jpg which in itself is strange since the ls before that does not show any .so file and you definitely execute it as an executable. You can't just start a shared library on the command line like that.

[Domodo]

Do you know how I can change the compile and link flags in Eclipse to generate a library and not an executable? I have read several tutorials but but no one tells how to generate the .so file.

[rolfk]

It's a long time ago that I used the Eclipse based gcc toolchain from NI to create any code for the cRIOs. I found the Eclipse project configuration anything but intuitive or even easily changeable after setting up a project in a certain way. Something always seemed to stick around somewhere from the old settings without being able to find the place to change it.

My current mode of operation for such projects in both desktop and real-time Linux is a simple Makefile and invoking that with the standard make tool on the target system. The main magic in creating shared libraries instead of executables is to pass the flags -fPIC to the compilation of source files and -shared to the invocation of gcc when linking all the different object files to a shared library.