Hello, I am having jetson orin nx board. So i want to run .exe file of qt application which is created and builded in other ubuntu system. while running .exe in my jetson baord it was throwing an error, so i am thinking this is because of cross-compilation so how to make my jetson board as cross-compilation?
Hello,
Thanks for visiting the NVIDIA Developer forums! Your topic will be best served in the Jetson category.
I will move this post over for visibility.
Cheers,
Tom
Is the file actually named with a .exe extension? This does not preclude the file being for Linux, but it is suspicious. If you run the command “file <program name>”, what does it say? If you try to actually run the program, what is the exact error (maybe it is a missing library, maybe it something else, the error should show something useful)?
Hi,
Please refer to the guidance in
Jetson Linux API Reference: Setting Up Cross-Platform Support | NVIDIA Docs
hello, i was created a Qt application code in my laptop and then i have installed same qt and also the required files was copied to jetson board. then i copied the .exe file which generated by the qt in my laptop. using that file i was replacing the file in jetson board at that it is unable to execute that file? so i need a cross compiler for this . Is their any files or libraries for this problem?
Hi,
We would suggest compile the application on Orin NX since the required libs for x86 and aarch64 may be different.
when i am compile the code in laptop and copying generated .exe to jetson board their i am trying to run that .exe file. at this time binary file error was throwing
no i am using same files and libs in both the systems. when i tried to run using copied .exe only it was throwing error but when i build the code in jetson board that .exe is running fine!
Binary executables on an ordinary PC or laptop are an x86 architecture. Jetsons are an aarch64/arm64 architecture. Unless you are using cross tools and cross compiling the only way your laptop will work for build is if it is also aarch64/arm64 (a few such tablets and laptops exist, but by far I would expect your executable to fail with the wrong architecture).
Building on the Jetson itself would build the correct architecture, and you wouldn’t have to worry about cross tools.
okay what cross tools or cross compiling i need to install? and what is the process ? can give me the info in detail about cross tools and cross compiling
Hi,
You would need to clone the rootfs from the target device and mount to your host PC. Please check
Jetson Linux API Reference: Setting Up Cross-Platform Support | NVIDIA Docs
okay but i cant able to do for more devices right! is there any compiler that will matches the jetson board? when we compile using that compiler?
You could skip cross compile just by compiling on the Jetson itself. That’s the easy way. Jetsons, especially Orin, have a lot of computing power like a desktop, and so about the only reason for not working natively, other than perhaps some business reason, is required disk space. One can add temporary memory for this, e.g., a USB external drive or SD card (depending on model of Jetson).
To start, do you have any experience building for the ARM architecture? What languages are you using that are compiled, e.g., C or C++? What follows is not an answer per se, but it is something you need to understand to set up for cross compile. The guides which NVIDIA publishes for Jetsons do have information for kernel cross compiles, but that’s the simplest case. It gets complicated.
Terminology: You are either building for “bare metal”, or for “user space”.
- The Linux kernel itself does not use any link libraries. The kernel is what actually provides that ability (indirectly; it is a component of the ability to use libraries). Thus your only concern is the correct cross compile, and there won’t be anything else required once that is met.
- User programs are not “bare metal”. User programs can link to libraries, and to access any part of the system, the program makes system calls to the kernel. There are conveniences to this, e.g., this is how automatic allocation of local variables in C exists. Bare metal does not get automatic allocation of memory for local variables in C.
- A kernel module or a kernel or a bootloader will be bare metal. Any program a user runs on command line will be user space.
The anatomy of a user space program has in part this:
- A free standing program can be built that does not use linked libraries, but this isn’t done very often since it means a larger size. Even if not using this, one might need some static libraries (these usually have a file name of the format “
lib...something.a”), or one will more likely dynamically link (these files usually have a file name of the format “lib...something.so”). - Dynamic libraries have to exist for user space at the time of linking or running.
- Static libraries have to exist for user space at the time of linking (the content gets copied in, and so external linking is not needed during run time).
- Linking requires a “linker” tool. To see the default libraries available on any Linux system run “
ldconfig -p”.
Cross compilers usually have names like this example:
aarch64-linux-gnu-gccaarch64-linux-gnu-g++
Native compilers usually have names like this:
gccccg++
That’s enough to work for bare metal. To go to user space you would also add a cross linker. A cross linker runs on one architecture, e.g., a desktop PC’s x86/x86_64/amd64, but produces output for another architecture (in this case 64-bit ARM, sometimes abbreviated as aarch64 or arm64). Cross linkers are similar: Then link libraries that are of a different architecture than that which they run on, e.g., they link aarch64 64-bit ARM libraries while running on x86/x86_64/amd64 host PCs.
If you build a C or C++ program, then typically you have a number of source code files. After building each file you have unlinked object files, typically with a file name of “something.o”. By themselves, object files are not of use. One must combine them in a link stage after compiling. So it is a compile then link set of operations that create the final binary executable.
If you were building only a kernel, then you could set an environment variable to find the “aarch64-linux-gnu-” files; a single directory probably includes these (and a lot more):
aarch64-linux-gnu-gccaarch64-linux-gnu-ldaarch64-linux-gnu-as
For a bare metal kernel build, as a convenience set up by the kernel people, if you export environment variable “ARCH” to “arm64”, and export environment variable “CROSS_COMPILE” to the tool location, e.g., it might be “/usr/bin/aarch64-linux-gnu-”, then you’ve set up most of what you need. For user space it gets a lot more complicated because now you must install the entire set of all arm64 libraries you need and all aarch64 cross linker tools onto your host PC. Then you must configure your build to use those cross tools. User space programming does not typically have any of the automated setup you get from cross build of kernels (those environment variable exports are supported by the kernel’s build system; you might need to manually write the correct commands in a Makefile for user space).
Incidentally, if you have a binary executable you’ve compiled on the host PC, then you can do this to see what is dynamically linked:
ldd <program name>
You could then compare it to what the default linker path provides:
ldconfig -p
The actual libraries are known as the “sysroot”. Building each library via cross compiling, starting with the more basic libraries (one library can dynamically link others; you can only build the ones with no other dependencies, or ones which depend only on what you’ve already built), and then working your way in until you’ve manually cross compiled a spaghetti mess of libraries using the cross tools. Only then can you link all of your .o object files. The simplification is that if you already have the libraries, and you have the cross tools, and you know how to configure your build to use those cross tools and sysroot, that you can copy them from the Jetson one at a time to the proper place.
Copy one at a time is a real pain. Building them yourself is by far even more painful. However, if you have a clone of the rootfs on the Jetson, and if that clone is loopback mountable, then you can simply loopback mount your clone, and then any link libraries required (the sysroot content) succeeds if you’ve told the cross tools where that loopback mount is at (basically configuring the linker).
Cross compiling a kernel is not bad, and the official documents for your specific L4T release has what you need. Once you’ve set up for a kernel cross compile it becomes very simple. Setting up for user space is not simple
actually i am using for qt. in that aarch compiler is there but issue with the make file. i am unable to add the aarch make file in qt when build the application. i am compiling with aarch compiler only but issue rising at linking stage with make file only.
Naming the arch is not sufficient. You still need the cross tools being named instead of the native tools, and you need a development environment sysroot. If you were to make it possible to natively compile on the Jetson, and then clone this with a loopback mountable raw clone, this would give you the entire sysroot. Add the cross tools, and adjust Makefile content to use the cross tools and libraries of the clone, and it should work. The trick is that you will need the development content (e.g., headers and libraries, not just libraries) for building what you want.
Compile stage uses headers, but link stage is when the cross linker must be used along with a sysroot that has the correct libraries.
can you give the what are the possible ways are there to cross compile the jetson orin nx board?
Hi,
Please follow this to set up the environment:
Cross-Compilation in jetson orin nx board - #13 by DaneLLL
You have to clone the image from the Orin NX board and mount it to your host PC.
already i have flashed my board. while creating a clone of raw.img is there any format o jetson board or overwrite? ansd one more thing i did not find the raw.img in jetson board, it is available in my host pc itself.
Hi,
It is confusing. Do you set up cross-compiling environment on host PC or Jetson device? Jetson device is aarch64 environment and you should compile the samples directly. The cross-compiling environment is for host PC.
i dont think so the setup of cross-compiling environment on host pc. yes , but i did not find any .img.raw in target board but i can find in host pc in linux of tegra folder. my doudt is about when we clone the image on host pc again it was telling to reflash at that time the data in the target boad will be reamin same or formatted?