How to add a Dynamic Library (SO) and needed additional libraries (i.e. boost) on a NI Linux RT?

[Petric]

I do have a sensor which can be connected over an Ethernet Port and an easy communication with a DLL. The DLL works fine when I wrap it with the «Call Library Function Node». As I wanted to run the sensor on NI Linux RT, I found that tutorial (http://www.ni.com/tutorial/14690/en/). So the sensor manufacturer compiled me an so with help of that tutorial an this tool (http://www.ni.com/download/labview-real-time-module-2017/6731/en/) .

Then I struggled first with moving the so to the /usr/local/lib on the RT Target. I tried it over WebDAV and mappend the traget (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019PlESAU). But I do not have no write access to the /usr/local/lib folder. The only folders I can add a file are:

• /home/webserv
• /home/lvuser
• /tmp

So I moved the file to /home/lvuser linked it in the «Call Library Function Node»:

Then I run the VI, with this node in it, and the Deployment Progress is waiting (for ever) by waiting on a respond:

When i cancle this, the Following massages pops up:

Here we guess that, that the boost libraries are probably missing. Right?

So I figured out that I can connect the Target to a network with internet access and connect the shell  over an SSH (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8bQSAS)

And with “opkg list| grep boost” I found some boost packages and Installed two with “opkg install boost” and with “opkg install boost-dev” which worked fine.

But the massage with the undefined symbol is still coming when I try to run the vi.

Does anyone have an idea how to solve the Issue? Or even what the Issue is? 😊

• Does the So need to be in /usr/local/lib? How to move it there?
• Does I need an other Boost library?

Thanks a lot

Patric, the one how never used Linux bevor…

[joerg.hampel]

Not sure if that actually is the core problem, but: I've never had problems with copying shared objects to /usr/local/lib.

Have you tried connecting to your system via SFTP? If you don't have a client already, you could use https://winscp.net/ as that makes it very easy and simple to copy files to/from your device. Just enable SSH on your device and connect with the user 'admin'.

[Petric]

Thank you Joerg

Over SFTP and your tool I can move it to /usr/local/lib. Unfortunately this didn't solve the problem:

And as a "DAU", I did delet a file on the target I should not... Is there somewere a recycle bin (like in Wondows) wer i can take it back?

[GatorChomp]

Hi Petric,

In my experience, an undefined symbol error is typically a problem with how the compiled file was linked.

This is my (extremely limited and hopefully correct) understanding: Essentially, when you compile a C or C++ binary that uses an external shared library, the binary needs to be "linked" to the dependency. This tells the binary where to expect the dependency and how it should be accessed to get to the functions used. You'll get an undefined symbol error if:

• The dependency is missing or in an unexpected location on disk
• The dependency is somehow significantly different from the one originally linked against
• Linking was not completed properly

Can you speak with the provider of the shared object to understand what dependencies they used and how they configured the compile tool chain? Did they have this shared object running successfully themselves or did they just build it? Most commonly we see this problem due to improper setup or use of the sysroot (which is a copy of the RT file system to be used for linking and dependencies when cross compiling). For example, they may have placed the libraries linked against in different places in the sysroot than they are on your system.

A very easy way to avoid this is to perform the compilation of the code on the actual target to be deployed to with all dependencies present (gcc and g++ are in the opkg repo). This avoids any of the common sysroot problems and ensures that the linked files are in the correct place. 

[Petric]

Hi Charlie,

Thanks for the hints.

I did install the package Binunits opkg install binutils and checked the needed libreries of the so:

/usr/local/lib# readelf -d libOptimessHLS.so

Dynamic section at offset 0x1211e8 contains 24 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
0....

All those *.so are "standard" Libraries and locatet in /usr/lib/ or /lib/

Therfore I guess it's not a sysroot issue, as he can't choose it, when he compiles the file.

[GatorChomp]

Hi Petric,

Interesting. I'm assuming all dependencies were install from opkg?

One other thing you can check is that the *.so is actually looking in the right place for the dependencies by using "ldd" on your *.so file (which you'll need to install from opkg). For example, I have a test application I built and linked against a shared object I built previously. If I use ldd on the executable with the *.so missing or in a different place on disk than expected, I see the following:

You'll notice that this shows the dependencies and where they are being loaded from, and that it calls out it cannot find my shared object (libmyLib.so) at the top. I did this with an executable, but it will work on a shared object file as well. You can use this to confirm that:

1. What the sub-dependencies of all your library's dependencies are.
2. If the *.so is actually able to find everything it needs in the place it expects. 

If everything is present and that command is able to find it, then you're correct and it's likely not a sysroot/linker problem of the typical variety.

[Petric]

Dear Charlie,

Thanks again.

No the "own" *.so is not installed from opkg. I moved ith to to target with WinSCP (as you can see above). The rest is installed with opkg.

I also did "ldd" and found all dependencies. But also :

ldd: warning: you do not have execution permission for `./libOptimessHLS.so'

Why do I not have permission? And could that be the problem? How to get permission?

Here the rest of the "ldd". I there anything else suspecting?

Thanks

Petric

[GatorChomp]

Hi Petric,

I also did "ldd" and found all dependencies. But also :

ldd: warning: you do not have execution permission for `./libOptimessHLS.so'

Why do I not have permission? And could that be the problem? How to get permission?

---

Ah, interesting. I'm not sure that this is the actual problem but we should fix that before trying anything else. Typically when you copy a file over it won't have execute permissions but you can change that from the terminal. You can check permissions using the "ls -l" command, then you can change permissions using chmod or WinSCP. 

Notice after the initial transfer, that the file only has read/write privileges. 

To fix this from WinSCP, right-click the *.so file on the remote device and choose "Properties." You'll want to give the file full execute permissions:

Try using it again in LabVIEW after making that change. Again, I'm not sure that this will resolve the issue at hand but my understanding is that shared objects on Linux need execute privileges. 

---

Here the rest of the "ldd". I there anything else suspecting?

---

Not as far as I can tell. It looks like it's able to map all the dependencies to items present on the system. 

[Petric]

Dear Charlie,

Thanks for the permanent help. As you suggested the privileg's are not the problem. I did "ls" and also changed the properties with WinSCP. The Sensor Supplyer also did a "dummy" *.so which only replays an ramdom number. We also have no execution permission but it works when I call it from LabVIEW with the "Call Lybrary Function Node".

The Sensor Supplyer told me, that he needs some boost funktions, but we can not see the dependencies from the libboost.so when we do lbb. He was now to figure out how to link it correctly, as he assumes that the compieler does link anything (even when its not present on his PC) and search's it then in the NI target. Any idea on that?

UPDATE: We figured out that he works with boost_1.65.1 and NI RT Linus has boost_1.63.0. --> He has to compile it once more with boost_1.63.0. We hope that works.

I keep you updated.

Patric

[Brian.D]

Hi Patric,

I would still expect ldd to show the dependencies from libboost.so regardless of the version, so I'm not positive that just compiling with boost_1.63.0 will fix the issue.

-Brian