NSight include library from *target* machine

Hi guys,

I’m supporting a colleague with NSight and I’m a little confused how to include libraries that are on the target device.

They write their software (CUDA/C++) in NSight on the host machine and then the application is cross-compiled and then ran/debugged on the target machine (Jetson TX2) over the network. We want to include a library (libgps / GPSD) in the ‘make’ process for the target machine but we are unsure how exactly we do this, or what is common practice.

I’m assuming I need to bring the aarch64 libgps library into the host machine(NSight) somehow, but I imagine I need the Jetson TX2’s aarch64 version of this library, or maybe I can specify in NSight where to find the libgps library on the target machine?

I would appreciate any guidance on this matter.

David.

You’re basically talking about “sysroot” files…the files which are needed to link against or to source while building user space software. Linaro and other cross compile suppliers only provide the minimal sysroot. While some cross architecture packages might be available on your host you could end up custom building a large number of support packages before you get to the packages you want. You could instead install what is needed for development on a TX2, clone this, loopback mount the clone on the host, and then sym link to the read-only loopback mount.

Setup depends on distribution, but if you look at “/lib” or “/usr/lib” you’ll typically find a subdirectory named for the architecture which is supported. In the case of Ubuntu and a TX2 this implies the content for linking needs to be in either “/lib/aarch64-linux-gnu/” or “/usr/lib/aarch64-linux-gnu/”. In the case of include paths you could add a “-I/where/ever/it/is/clone/mounted/usr/include” or similar.

As to how to actually point NSight to this someone else will need to answer.

Note that on an R28.2 TX2 I can find the installed location of libgps via:

# ldconfig -p | grep libgps
        libgps.so.22 (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/libgps.so.22

Regardless of whether you add a symbolic link to a loopback clone mount or whether you simply set up eclipse to know where to find the loopback clone mount this would make the actual environment available. You just have to be sure all the dev packages are on the Jetson before you clone. If you later update your Jetson you can use rsync to update the clone.

Some clone information:
https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/

You could also just scp individual files to the correct location on the host under “aarch64-linux-gnu”, but this is a pain since even the library will need to link to other libraries…which link to other libraries…etc.

Thanks, Linuxdev. Great detailed information and advice as always!

Our team literally just resolved the issue, it seems you don’t need the ‘lib’ prefix of ‘libgps’ when specifying which on-target library you wish to include in your build in Nsight.

Thanks.

David.

That’s tradition…it isn’t just nsight. The gcc linker tools know the file is prefixed “lib” and has the “.so.something” suffix. NSight is passing that information through to the linker.