2019 C/C++ Compile Tools

[paul.r]

I am currently working on building the source files for a DLL into a .SO file that will be consumed by LabVIEW code in an executable that will be deployed to an NI RT target. I have successfully built the .so file using Eclipse and the instructional guide provided by NI. (Link to instructional below.) When I try and deploy a simple test executable to the target and use a CLFN to call my .SO file, I get an error that I believe is related to the source files I used to build being out of date with what is actually on the controller. Specifically, the version of libudev. 

Is a more recent set of source files to build C/C++ applications against available? I found the second download link, but I am not sure if that is what I want - it gives me a .tar.xy file that I have no idea what to do with - I was expecting a zip containing something similar to the files contained in the 17.0\x64 folder you get when you download the files with the Eclipse instructional.

http://www.ni.com/tutorial/14625/en/  

https://www.ni.com/en-us/support/downloads/software-products/download.gnu-c---c---compile-tools-x64....

[GatorChomp]

Hi paul.r,

The 2018-2019 toolchain at the link you shared is currently the most up-to-date version of the C/C++ toolchain.

• Did you use the 2018-2019 toolchain with the tutorial you linked? Or the 2017 toolchain that the tutorial was originally written with?
• What is the specific error are you receiving?

The *.tar.xz is a grouped an compressed set of files similar to a .zip file. You should be able to extract it using your preferred program (I use 7-zip personally). You might get a warning or two when extracting the files but they can typically be ignored, and you'll need to first extract the .tar file and then unpack that. 

[paul.r]

Hi Charlie,

Thanks for the response - I used the original 2017 tool chain that the tutorial was written with.

I am currently getting an error 13 from the CLFN when I try to run the exe. A coworker (who has much more experience with Linux than I) who had tried to get this working informed me that the issue was related to the source version of libusbdev being out of date - I have pinged him on how he figured this out, but I would be inclined to believe he had a good reason for assuming that was the root cause the problem. 

And, ah I see - I did a quick internet search for the file type and it all seemed to be linux specific, so I assumed that the download wasn't what I was looking for. I will try unpacking the file, and rebuilding then report back.

Paul

[paul.r]

Hi Charlie,

So I was able to rebuild the .SO file against the new source files, however I am running into the same issue when I attempt to deploy. (Error 13 from CLFN)

Any ideas? Could this be related to using 32 bit LabVIEW? Should I be using 64 bit?

[GatorChomp]

Hi paul.r,

Using 32-bit LabVIEW shouldn't be an issue since there is no LabVIEW Real-Time Module for 64-bit LabVIEW. That's almost certainly not the issue. 

Instead, I'd recommend checking if the shared object is able to find its dependencies on the target. Note that you'll need to use the opkg package manager to install the correct utilities to do this but there are two common options:

• readelf - this utility is installed as part of the binutils package. 
• objdump - this utility is installed as part of the binutils package. 
• ldd - this utility is its own package.

You can grab these by running "opkg update" and then "opkg install <package name>" on the target.

I recommend the ldd approach as it will allow you to see the full dependency hierarchy if you need to. There's plenty of documentation on using the command online which I would recommend referring to, but here's the man page to get you started: 

[paul.r]

Great, thanks I will check that out. One quick question, does the location of the .so file on disk matter? I have it in the nested 'data' folder that gets built with the .exe.

[GatorChomp]

The location of the *.so will only matter in terms of how your calling application finds it unless you linked dependencies using relative paths. I believe you would have had to do that manually so I'd be surprised if that were the issue, and checking with ldd would show that as an issue pretty quickly. 

Basically, for *.so files installed manually to the system there are two recommended locations:

• If the *.so is application specific, you can have it in a private folder for the application (this is what you're currently doing)
• If you want to install it for multiple use cases, I'd suggest installing it to the /usr/local/lib directory. This is the recommended location for libraries which are not part of the kernel and are not managed by the system package manager (opkg).

[paul.r]

Hi Charlie,

So I was able to get ldd installed on the device, and this is the output - 

admin@NI-cRIO-9033-01A23322:~# ldd -v --verbose /C/ni-rt/startup/data/libHIDAPI.so
ldd: warning: you do not have execution permission for `/C/ni-rt/startup/data/libHIDAPI.so'
linux-vdso.so.1 (0x00007ffcc75c0000)
libc.so.6 => /lib/libc.so.6 (0x00007fa37d8ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa37de4d000)

Version information:
/C/ni-rt/startup/data/libHIDAPI.so:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.7) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Any clues on where to go next? I don't see anything that looks like an obviously missing dependency. This was the output from running with the -d option, which if I understand correctly would show missing dependencies?

admin@NI-cRIO-9033-01A23322:~# ldd -d /C/ni-rt/startup/data/libHIDAPI.so
ldd: warning: you do not have execution permission for `/C/ni-rt/startup/data/libHIDAPI.so'
linux-vdso.so.1 (0x00007ffce61a4000)
libc.so.6 => /lib/libc.so.6 (0x00007fa1927cf000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa192d6f000)

[paul.r]

Just following up on this, below is the code I am trying to get running on an NI target, in case that provides any clues about what possible next steps should be.

https://github.com/signal11/hidapi

[GatorChomp]

Hi Paul,

I believe you can also use the "-r" option to double-check for missing functions as well. However, you are correct that it doesn't look like any of the object dependencies that the built object is looking for are missing. 

In this case, I think the issue might be execution permissions. Can you check what the execution permissions for your shared object are once it's deployed? You can check with the "ls -l <path to binary>" and look at the far left side. If all users have execute permissions you should see 3 x's there. If not, run "chmod a+x <path to binary>" to add execute permissions for all users. 

Another issue might be if the dependencies aren't getting linked to your binary for some reason. I'm surprised libusb and libudev aren't listed as dependencies given your previous comments and the repo you linked to. Can you provide more details about how you're compiling that source?