Best practise for cross compile for TEGRA TX2 application using opencv


My host is ubuntu 14.04 LTS that does not have any GPU

I need to develop application using opencv on the TEGRA TX2 that using GPU

I glad to hear solutions for cross compiling using opencv:

  1. opencv4tegra (ver 2.4.12)
  2. opencv3 (3.3.0)

I know that opencv depends on zlib,cuda, and other 3rd party libraries

how the besy way to compile my application on the host machine?



Hi alalieli,

Cross-compile of openCV is not officially support. Maybe other forum users can share their experience.

I also cannot answer, but have a tip which might make it easier for whatever setup you attempt (or at least give you a systematic method to put the pieces together).

Cross compiling a user space application means you need the cross environment for linking and any library involved (kernel space tool setup is simple even if bare metal coding isn’t, kernels don’t link to anything). To this end you’ll see published minimal sysroot support from cross tool distributors which are basically a collection of linker and basic system (think low level libc functions and the linker itself…perhaps with some additional “almost always needed” files). You’ll end up with a subdirectory somewhere named with the architecture to keep it separate from your host. One of those subdirectories will be “native”, the rest are “foreign”. Cross tools have an understanding that they are running on the one architecture, but using linker and other tools from a different architecture. Those files must be built up.

For example, my Fedora host PC has “/usr/lib/arm-linux-gnu/” since I have cross compile setup for armhf user space (my cross tools are aware of this naming convention and location). Find out where your foreign architecture sysroot files are, move them to an alternate name, and put a symbolic link in pointing to the correct directory of the loopback mounted read-only clone (or just add new symbolic links for individual files as you find the need). What shows as foreign on your PC will be there as native on your clone. It’s a perfect mirror image of the environment the app will run in. Just to emphasize, before you clone make sure you have any dev package you need.

Instead of using one file at a time and third party downloads (such as from Linaro which provides the best of high quality well-known free tools and sysroot files), consider a clone of your rootfs on your Jetson as a perfect sysroot replacement. With loopback mount this will include the exact and entire environment of your Jetson including every dev package you’ve added and every update you have at the moment of clone. If you’ve installed the dev versions of everything you’d need onto the Jetson prior to cloning, then it means your clone will be a pop-in replacement for this one-file-at-a-time gymnastic internet search and download effort. Or simply use a symbolic link into the loopback mounted clone whereever a compile says some specific file is missing.

ldd is a good tool to look at a file and see what it wants to link to…this includes use on a lib file to see what this in turn points to.