myRIO doesn't find my .so shared library

[NiktuStark]

Hello everyone,

I have developed a shared library .so to execute on a myRIO device. I moved my shared library to the path /usr/local/lib of the myRIO. When I execute the .VI I get this error: 

Deploying RT.viRT.vi loaded with errors on the target and was closed.
LabVIEW: Failed to load shared library libsolve.so:solve:C . Ensure that the library is present on the RT target. Use either MAX to install NI software or FTP to transfer custom libraries to the RT target.

Some idea? I reinstalled the software on the myRIO but I still have this error (I comproved if the shared library is at good path with filezilla and Eclipse.)

Thanks in advance

[rolfk]

How did you compile that shared library? Did you use the NI Eclipse distribution? What cRIO do you use and did you use the right version of the Eclipse toolchain (ARM or x64)?

Did you define a soname in the compiler options? And last but not least did you run ldconfig from the command line on the target after you moved the library?

[NiktuStark]

Thanks for your answer, that was fast!

I compiled it with the Eclipse distribution. I'm not using a cRIO I'm using a myRIO and yes I used the ARM toolchain. 

I dont understand your last questions, sorry. A soname in the compiler options,...what do you mean? And the last what is Idconfig? I just dropped the .so to the device using filezilla.

Thanks in advance,

Carlos

[rolfk · Accepted solution]

Well lets try the somewhat more detailed explanation:

First the soname setting that is a compile/link time setting in the project for the shared library. I don't have a computer with Eclipse installation handy but it is somewhere in additional flags in probably the linker settings where you would for a shared library named libfoo.so.1.3.6 add something like:

-Wl,-soname,libfoo.so.1

Then you would copy the resulting shared library over to the linux system.

cp libfoo.* /usr/local/lib

After that you need to do a few extra things:

1) change the access rights for the file, otherwise ldconfig might not recognize it as an executable file and just ignore it:

chmod 0755 /usr/local/lib/libfoo.so.1.3.6

2) create a softlink with the simple shared library name:

ln -sf /usr/local/lib/libfoo.so.1.3.6 /usr/local/lib/libfoo.so

3) after that you should run ldconfig to add the new file to the shared library cache

ldconfig

This will enumerate all shared libraries in the default library locations (/lib, /usr/lib, usr/local/lib, 64 bit version of them and other directories listed in /etc/ld.so.conf) and add them to the cache file at /etc/ld.so.cache.

With

ldconfig -p

you can then verify if the new library is listed in the known cached shared libraries

[NiktuStark]

Thanks for your repply, I did all the steps. The shared library is at the cache, and the LabView does not find it. I don't understand. So much frustrated.

My .VI stills launch the same error. Any more idea? 

I call the .so at a call function node in a .VI inside the embedded system (the .VI is just the node). I just click the run (arrow) and while debugging, this error shows.

Thanks in advance,

Carlos

[rolfk]

So with which LabVIEW version is this?

And one possibility that your library may not appear to be present eventhough ldconfig saw it and added it to the cache, might be that it links to some external libraries that you have not yet installed on your systems. What sort of shared library is this? What do you do in there and what functions do you call?

[NiktuStark]

Sorry for the late answer...

I'm working with Labview 2015 (32 bit). My libray is for solving QP convex optimization problems and within it I have a lot of different functions (matrix calculations, KKT conditions...) . I'm using this libray to construct MPC problems (I need more flexibility on my research than the provided by the MPC library from the Control & Design package) and the final objective is to implement this algorithms into the myRIO device.

I think I have all my functions well linked, if not my library couldn't be compiled right?

Regards,

Carlos

[NiktuStark]

I finally solved it, I had problems with the compilation in the Eclipse environment (2014). I used gcc into cygwin environment and all worked.

I really appreciate your help,

Regards

Carlos

[rolfk]

---

@NiktuStark wrote:

I think I have all my functions well linked, if not my library couldn't be compiled right?

---

Nope!

The ELF format has a different philosphy than the COFF format used for Microsoft DLLs. The final linker stage will be happy to link together a shared library which does not contain all necessary symbols, marking them simply as external references that need to be resolved at load time. If you happen to have the package installed that contains these symbols, all is well otherwise the loading of the shared library will fail.

It's not so much different to DLLs in fact, except that with DLLs you absolutely have to link in an import library for all referenced symbols, which does then load the dependency and link to the symbols in that secondary DLL. If the dependency can't be found at load time, the standard import library code will cause the load of the primary DLL to fail and you get in fact the same effect. In ELF the requirement for an import link library has been removed. The dynamic loader will simply search the currently loaded modules and then the registered modules in the ldcache for any symbol that isn't implemented in the actual shared lib. If found it will link to that symbol, if not it will fail the load of the main shared library.

[sanju254]

I finally solved it, I had problems with the compilation in the Eclipse environment (2014). I used gcc into cygwin environment and all worked?

Please provide me that how to use gcc and flow of .so file execution.