I’m a total beginner in Nvidia’s embedded computing. I’m running a tracking and recognition program which is a combination of several open source software like It’s implemented using visionworks, TensorRT, openCV for tegra, gstreamer, cuda and shared libraries (.so files) those come with jetpack. I can compile and run the program on jetson tx2 natively. I am looking for a solution so that i can cross-compile my project which uses all these above-mentioned libraries (.so files ). Can’t figure out if I should compile jetson-inference, visionworks, etc in my host PC(Ubuntu 16 + jetpack 3.3 host) or not? If yes, then is there any guide and toolchain and other resources available to achieve that? or can I compile the sample codes of jetson-inference and visionworks natively on TX2 and copy them over to host and use those binaries to cross-compile on the host computer? What is the optimal way?

My host computer is Ubuntu 16.04 without Nvidia GPU and got Jetpack 3.3 installed. First attempt was to cross-compile the sample in Nsight. I’ve tried to compile a couple of samples especially the ‘box-filter’ as mentioned here
Even though I’ve configured the path in bashrc properly, but the error mentions “nvcc not found”

xiaoyao@dell:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Sun_Nov_19_03:10:15_CST_2017
Cuda compilation tools, release 9.0, V9.0.252

The second method was to mount the L4T img into my host computer so that I don’t need to worry about the library and header files. I made changes in the CMakelists.txt file as well. It also didn’t work.

Is there any other way or pros and cons not mentioned here? Looking forward to your suggestions. Thanks

Nsight wasn’t intended for running directly on a Jetson. Don’t consider any failure to make this work directly on a Jetson as a build issue…it won’t happen even if you do everything correctly (porting would be required, and I’m guessing a lot of it).

You have basically two issues to deal with before cross compiles will work correctly. First, there are some tools which must execute on your PC architecture, but work with arm64/aarch64/ARMv8-a output. This is the cross toolchain. Any compiler or linker used in the process counts for this.

The main compiler is your typical cross compiler. I believe nvcc produces code changes which do not have that dependency…instead it injects code which depends on the architecture of the GPU, but not the CPU. There is an arch setting for GPU compatibility and this is enough to make it work on a TX2 versus a desktop PC, so on…thus the nvcc tool probably doesn’t need any modification. However, if you have a CUDA 9 compiler, and your GPU system has CUDA 10, then it won’t work. You’d need to upgrade your nvcc to handle CUDA 10 if that is the case, but there won’t be a need to search for any sort of cross-nvcc.

The gcc compiler does require a separate compiler. I’m guessing you already have a cross compiler which runs on a PC and outputs arm64. Once code is generated it has to link. The cross linker is the other half of cross executable programs. If your cross linker is installed, then this plus cross compiler and nvcc of the correct CUDA release are all you need in terms of execution of compile. Environment to link with is the next issue.

Once this is in place, your own code is built by the compiler. Usually a program will be complicated enough that it then needs the cross linker (kernels don’t link and kernel code doesn’t need a cross linker). So there is the grand question many people come to ask…how to set up the environment so that the cross tools work? A loopback mounted clone image is a great way to do this, but you could just copy any library on the Jetson directly to your cross environment setup. This is basically what the “–sysroot=something” option is about.

A lot is involved, but without a specific issue to look at it is hard to answer. If you want to use a clone, then see this: