Can't load FPGA Interface C API Linux shared object in call library function node

[J.Harv]

Hello-

I'm having trouble trying to load a Linux shared object generated from the FPGA C Interface API. I get Error 7 file not found, or file could not be loaded.

I'm using LabVIEW 2020 on Windows 10 to write an FPGA application for a PXIe-7846. This looks good. I then use the FPGA C Interface API and generate 4 files: NiFpga.c, NiFpga.h, my application .h file, "myapp.h" and bitfile "myapp.lvbitx. These files get transferred to the target system with the hardware that runs Linux.

The system with the hardware that I'm developing this application for is running LabVIEW 2020 on Red Hat Enterprise Linux 8.5. I take the C API output files and run them through the gcc compiler on the system using a make file to generate my application shared object library file. "myapp.so". This works correctly, no errors, and I get myapp.so file.

To narrow down the problem, I open a blank VI and drop a call library function node. I select myapp.so. This seems to work, and the function drop down populates with the expected LabVIEW FPGA functions. I select something simple, NiFpga_Abort, with return void. Now the problem, when I click ok to close the call library function dialog, a file dialog appears asking me to "Find the Shared Library Name myapp.so", the so file that I've already selected. I can even see it there in the file dialog box. When I select it, and click ok, I get a error from LabVIEW:

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.
The file "myapp.so" could not be loaded.
Select another?

If hit ok to "select another" and point it back to the so file I get the error again. If I hit cancel the run arrow is broken with error: Call library function node "myapp.so": Library not found or failed to load.

So, the file is clearly there, and LabVIEW seems to be able to see the FPGA functions, but for some reason can't load it? I have other shared objects for other vendors drivers built with make files that work fine with the call library function nodes. I don't know what is different about the NI FPGA C or generated SO file? I'm not sure what to try next. Please help. Thank you!

John

[James_McN · Accepted solution]

Hi John,

I seem to remember you will get that same error if a dependency of the library is missing.

If you use the ldd command (ldd myapp.so) it should list the other libraries it needs and show if any are missing or failing to load.

It can also be a search directory problem but as long as you provide a full path on the call library function node that should be OK.

Cheers,

James 

[Donald265]

I found similar topic here https://forums.ni.com/t5/LabVIEW/Library-Function-Node-in-Linux-Functions-Not-Found/td-p/899987 MyLabCorp Login

[rolfk]

There is no bug in LabVIEW that I’m aware of that would cause something like this! That other thread also is bogus as it talks for instance about the toUpper() function being a standard C function. The specific spelling with uppercase U sounds like it’s not just a typo but standard C function are usually always full lowercase including the toupper() function so that error description is not accurate in one or the other way.

The shared library loader under Linux is fairly complex and has also a limited number of search locations for dependencies. The details are different than under Windows but overall can cause the same problems. Shared libraries, including dependencies and dependencies of dependencies and so on, need to be placed in certain specific directories that can be configured in true Unix fashion through a number of configuration files.

If your shared library can’t be loaded for some reason you need to start debugging it’s loading and not just blame the calling app. Try to use ldd on the command line to see more information about your shared library. You also usually need to run ldshared after copying a shared library into one of the configured directories, which will create a cache about what shared libraries are available on your system. There are many different Linux tools to find out more about your shared library and its loading, but they are all command line tools and require reading the according manpages.

LabVIEW simply uses the dl loader functions to access shared libraries and if that doesn’t work, something in the dl loader failed, not in LabVIEW!

[J.Harv]

Hi everyone-

Thank you for helping with this!  James got it first.  I used the "ldd" command and there was a dependency that was not found.  After a bit of digging it was one of our libraries that I don't control, but here's what happened.  This solution is specific to our setup:  The missing library was recently updated to 64bit and referenced with an environmental variable.  I updated the path in bashrc and reloaded.  Now ldd says it's found and my *.so is working fine with LabVIEW!  Thank again to everyone that responded here, much appreciated!

~John