Import Shared Library Wizard .so file

LVstruggles · ‎09-24-2020

I'm new to the import shared library wizard and I'm trying to import a .so library we've made to run on our MyRIO. I can add the .so file to our vi just fine manually, but when I try to do it using the wizard, I only get the option to select .dll files. The help documentation for the wizard says it can use .dlls, .framework, and .so libraries. Is this a consequence of using Windows for the development, but having a linux target? If I install LabView in a linux virtual machine, will I be able to use the wizard with .so?

For context, this is a necessary step because we do our algorithm development in Matlab. If anyone has a suggestion for a better workflow for compiling Matlab functions to run on a MyRIO, we're all ears!

rolfk · ‎09-24-2020

Windows does not provide functions to load a so file and even less for a framework . Frameworks are under the hood a directory structure but the Macintosh finder will display them as a file object and not let a user move into it.

Accordingly the import library wizard can only work with the shared library format for the platform it is running on.

In order to install LabVIEW for Linux you will need a valid installer and unless you are at an university with an educational site license that’s a full purchase as your LabVIEW for Windows license does not give you access to this. Besides LabVIEW for Linux is an Intel 64-bit compiled version and the import library wizard won’t be able to use your so library either since it needs to be compiled for ARM in order to run on the myRIO. You could get Matlab code builder to also create an x64 version of the so and then it would work.

But there might be an easier way to go about this if you can get Matlab to create a Windows DLL of that library to. It would require that Matlab uses exactly the same datatypes on all platforms it generates code for. If that is the case you can go after the import library wizzard into each VI and change the library name from <mylib>.dll to <mylib>.* and possibly adapt he library name except for a prepended “lib” that the .so file might have.

That all said Matlab generated APIs use their own memory managment contract when functions use variable sized buffers, using special datatypes in the form of structures and the import library wizard doesn’t know about managed datatypes. So its generated code will be not correct for them and cause crashes if you try to run those VIs without adapting them manually.

Rolf Kalbermatter
My Blog

natasftw · ‎10-04-2020

How many functions are you working with in that so file?

Depending on that answer, the easiest path forward might be to just write your own wrapper VIs. All the import wizard is going to do is make VIs with a Call Library Function Node inside and the appropriate inputs/outputs. If you've got a handful of functions, this takes a few minutes and is far easier than any other workaround.

If you've got a large number of functions, it might be worth looking at alternatives.

avogadro4 · ‎10-05-2020

This may not be precisely your issue, but in the past I've received a .so file built for win32 and successfully imported the library by renaming the .so to .dll. No idea whether that worked because someone made a mistake building the library, or if it's generally true that .so and .dll are similar enough to expect it to work this way.

rolfk · ‎10-05-2020

@avogadro4 wrote:

This may not be precisely your issue, but in the past I've received a .so file built for win32 and successfully imported the library by renaming the .so to .dll. No idea whether that worked because someone made a mistake building the library, or if it's generally true that .so and .dll are similar enough to expect it to work this way.

Sounds very bogus. .so files are typically ELF (Executable and Linking Format) files and that is a considerably different format file than Windows COFF (Common Object File Format) libraries with PE (Portable Executable) header. And as far as I know, LabVIEW does not incorporate any executable format library importer of its own but simply relies on the platform shared library loader. I'm not really aware that the Windows loader would understand the ELF format.

https://stackoverflow.com/questions/24997497/how-to-call-elf-function-on-windows

Rolf Kalbermatter
My Blog