Issue with cross compiling Qt5.9.1 (Qt Enterprise eval version) for Jetson TX2 board

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi Everyone,
We have received the x64 eval version of the Qt Enterprise Edition.

The Qt Enterprise Edition allows for generating Boot2Qt images for different embedded boards including NVIDIA Jetson TX1.

Our goal is to create a similar Boot2Qt image for the NVIDIA Jetson TX2 board.

On contacting Qt company, they directed us to the link Qt for Embedded Linux | Qt 5.15 which contains instructions to build Qt manually for a target device.

The directory qtbase/mkspecs/devices after installation of the Qt Enterprise Edition contains configuration and graphics adaptation code for a number of devices. The Qt company advised us to make a copy of the existing Jetson TX1 directory under qtbase/mkspecs/devices, rename it for TX2 and make changes to the contents of qmake.conf specific for TX2, if required.

I created a new directory ‘linux-jetson-tx2-g++’ under qtbase/mkspecs/devices replicating the existing ‘linux-jetson-tx1-g++’ directory under the qtbase/mkspecs/device.

I have the sysroot and the rootfs setup and provided the options below for the ‘configure’ under qtbase.
./configure -release -device linux-jetson-tx2-g++ -device-option CROSS_COMPILE=/64_TX2/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- -sysroot /64_TX2/Linux_for_Tegra_tx2/rootfs -prefix /usr/local/qt5

The ‘configure’ command above works fine when we select the ‘o’ for the Open Source Version of the Qt Enterprise version.

But when trying to make using ‘sudo make’, the compilation seem to be failing.

[b]L/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib -L/64_TX2/Linux_for_Tegra_tx2/rootfs/lib/aarch64-linux-gnu -L/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib/aarch64-linux-gnu -lpthread -licui18n -licuuc -licudata -lm -lz -L/opt/Qt-backup/5.9.1/Src/qtbase/lib -lqtpcre2 -L/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib -L/64_TX2/Linux_for_Tegra_tx2/rootfs/lib/aarch64-linux-gnu -L/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib/aarch64-linux-gnu
a/64_TX2/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/…/lib/gcc/aarch64-linux-gnu/5.4.1/…/…/…/…/aarch64-linux-gnu/bin/ld: /64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib/aarch64-linux-gnu/libz.a(compress.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `__stack_chk_guard@@GLIBC_2.17’ can not be used when making a shared object; recompile with -fPIC

/64_TX2/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/…/lib/gcc/aarch64-linux-gnu/5.4.1/…/…/…/…/aarch64-linux-gnu/bin/ld: /64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib/aarch64-linux-gnu/libz.a(compress.o)(.text+0xc): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol __stack_chk_guard@@GLIBC_2.17' /64_TX2/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/5.4.1/../../../../aarch64-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make[2]: *** [../../lib/libQt5Core.so.5.9.1] Error 1 make[2]: Leaving directory /opt/Qt-backup/5.9.1/Src/qtbase/src/corelib’
make[1]: *** [sub-corelib-make_first] Error 2
make[1]: Leaving directory `/opt/Qt-backup/5.9.1/Src/qtbase/src’
make: *** [sub-src-make_first] Error 2
v@v-VirtualBox:/opt/Qt-backup/5.9.1/Src/qtbase$
[/b]

Anyone came across this issue while building Qt?
Could this be an issue with my toolchain - gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu? I downloaded and installed this toolchain separately and this was not part of the JetPack 3.0 installation.

Thanks
M

2
3

It sounds like you need a missing library…perhaps you have the static version but need dynamic (which is what fPIC would change if the library were compiled with this). Link errors such as this would probably mean a missing sysroot item instead of a tool chain item. If you look here you’ll see there are basically three package types for user space:
[url]https://releases.linaro.org/components/toolchain/binaries/5.4-2017.05/aarch64-linux-gnu/[/url]

The tool chain itself is one item, but there is also runtime and sysroot. The tool chain by itself can build a kernel because the kernel is bare metal and provides a support environment, whereas a user space application consumes a support environment. Meaning a kernel makes it possible to add a linker and libraries, but user space expects those to be provided. runtime plus sysroot are that user space environment, and yours seems to lack what you are trying to link against. The part which is probably confusing is that you seem to have the library, but it is static and the linker doesn’t like it.

If you were to build something natively on a Jetson you might need to add a devel version of a package or some prerequisite library. I tend to add whatever I need on my actual Jetson, and then clone it…mounting the clone on loopback on the host and looking for my sysroot that way instead of via a minimal sysroot. You could of course manually copy into your sysroot’s “sysroot-glibc-linaro-2.21-2017.05-aarch64-linux-gnu/usr/lib/” whatever dynamic library you need from any valid source. libz.a is mentioned, do you have a libz.so somewhere?

4

i have a same faults on this step, and i don’t know how to do next ; On the side ,i must user opengl es,and argus api,in my application.Is there any solution to this problem?

5

I can’t answer, but probably nobody can answer without some details. Which JetPack release? Native compile or cross compile? If cross compile, which toolchain? What software are you building? What is the log of the failure?

6

Hi linuxdev, I followed your guide and I passed the errors: “undefined reconference to…”. Then I installed Qt5.9, and created a new project. But when I built, I got errors:
“skipping incompatible /usr/local/cuda-8.0/lib64/libcufft.so when searching for -lcufft”
“cannot find -lcufft”

… and other: -lnpps, -lnppi, -lnppc, -lcudart

But I didn’t use any Cuda function, I just used opencv.

I also found down files: libcufft.so, libnppi.so, libnppc.so, libcudart.so in /usr/local/cuda-8.0/lib64/

Can you tell me how to solve it? Thank you.

7

More recent OpenCV releases have CUDA enabled. Perhaps it wanted CUDA9, but I don’t know. Newer L4T releases use CUDA9.x.

Most complex software builds you might run into have a “./configure” step. Packages to be included or excluded, where to install to, so on, will need to be custom to your situation. I don’t have the software you have, so I can’t test, but basically I suspect most of what you are needing is either a configure step or a library of a different version. For configure you might want to run “./configure --help” wherever the file is (usually the root of the software, but cmake can do things differently).

A newer version of JetPack could flash a newer L4T. This would make it possible to use a newer version of CUDA. However, before going through all of that, I suggest you research which version of CUDA the current OpenCV is using.

As an example, I have a TX2 running L4T R28.2 here. If I run “ldconfig -p | grep -i opencv” I see that the hard link files are in “/usr/local/lib/”. Once there I can see “libopencv_core.so.3.4.0”, and check what it links to via “ldd ./libopencv_core.so.3.4.0”. Looks like my case links to “libcudart.so.9.0”, and this is in “/usr/local/cuda/lib64/”. It is important to know that “/usr/local/cuda” is always a symbolic link to the actual version. In my case “/usr/local/cuda/” is a symbolic link to “/usr/local/cuda-9.0/”. So my OpenCV is version 3.4, it points at CUDA 9.0. If I had multiple versions of CUDA installed (and I do on my host PC, but not on a Jetson), then I might mv my symbolic link of “cuda” to instead be “cuda-9.0”. Alternatively, I could make both the 9.0 and 8.0 versions available via configuration to ld.

My thought is that because some older version of CUDA was found and rejected, perhaps you simply need a newer CUDA. On the other hand, Qt itself, even using the most bleeding edge version, might think version 8.0 is too new. Knowing the right version of each dependency will save you a lot of grief, so this is what I would research, starting with OpenCV version and CUDA version (if OpenCV version is the same as yours, then you just need the correct CUDA version…but there is an entire chain of dependencies so it isn’t likely to be that simple) which Qt wants.

8

I use Jetpack 3.0, so the Opencv is 2.47. I recognized that I had libcufft.so, libcufft.so.8 and libcufft.so.8.0.64; so I changed all to libcufft.so. Then, the error: “skipping incompatible /usr/local/…” was dissappeared. But the error: “cannot find -lcufft” still exist. I also see the warning:

"Project MESSAGE: PKG_CONFIG_LIBDIR automatically set to /home/cat/Jetpack30/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/lib/pkgconfig:/home/cat/
Jetpack30/64_TX2/Linux_for_Tegra_tx2/rootfs/usr/share/pkgconfig:/home/cat/Jetpack30/64_TX2/
Linux_for_Tegra_tx2/rootfs/usr/lib/aarch64-linux-gnu/pkgconfig

Project MESSAGE: PKG_CONFIG_SYSROOT_DIR automatically set to /home/cat/Jetpack30/64_TX2/Linux_for_Tegra_tx2/rootfs "

In my directory: 64_TX2/Linux_for_Tegra_tx2/rootfs/ doesn’t have CUDA library directory. So, it should be have or not?

Also, actually, I don’t see the path in my host: /usr/local/qt5/lib
Thank you.

9

I don’t know enough to help you with CUDA setup, especially with older versions of OpenCV. However, if any library you used wants CUDA, then you need to provide CUDA of the version the library was linked against.

As a tool you can print what libraries your system sees in its default search path with “ldconfig -p”. To specifically see “-lcufft” grep for libcufft:

ldconfig -p | egrep libcufft

My TX2 has only CUDA 9.0, and ldconfig prints out that it sees libcufft.so.9.0 (along with a symbolic link to this). If you want to see what a particular libarary wants (libraries often want other libraries), then:

ldd /where/ever/it/is/libcufft.so.9.0

Any time you are mixing older libraries with newer libraries (crossing the CUDA-8/CUDA-9 version boundary), then incompatible versions will basically become invisible. You can name them, but it won’t work.

It seems JetPack3.0 was probably paired with CUDA-8, while newer releases are paired with CUDA-9. I don’t have any way to tell you what is mixed up in your current system, but it seems you will need to make sure everything in your environment is all CUDA-8 or all CUDA-9.

10

Hi,

I am getting same issue. Anybody successfully did it?

Please share your solution. It would be very helpful.

Thank you.