Qt and Jetson TK1 - Compiler Toolchain Setup Help

webzoid

I've since attempted to set-up Qt for cross-compilation for my TK1 module and it has been fairly unsuccessful.

On my Ubuntu 16.04 host machine, I downloaded the arm-linux-gnueabihf compiler from the Linaro site and extracted the package to my home directory. I also installed Qt5 using the "apt-get install qt5-default" command and then QtCreator "apt-get install qtcreator".

I then created a "tk1" folder within the home directory and "scp'd" the /usr/bin, /usr/lib and /usr/include directories from my TK1 target machine up to the "tk1" folder - maintaining the original directory structure.

Looking at the Qt installations, running "qmake -v" on the TK1 tells me that QMake version 3.0 is being used and Qt version 5.2.1 in /usr/lib/arm-linux-gnueabihf.

Looking at the host machine, running "qmake -v" tells me that QMake is also version 3.0 and that Qt version 5.5.1 is being used in /usr/lib/x86_64-linux.

Now to Qt Creator on the Ubuntu host machine...

I've added my device into the Tools -> Options ->Devices list and have successfully tested that I can connect to it via its IP address.

Tools -> Options -> Build & Run -> Compilers show that GCC has been detected in the /usr/bin folder of my host machine. At this point, I add a manual entry for the arm-linux-gnueabihf-gcc and arm-linux-gnueabihf-g++ compilers which are in my home directory (from the Linaro release).

Tools -> Options -> Build & Run -> Qt Versions show two version of Qt installed on my host machine: 5.2.1 in /home/ubuntu/Qt/5.2.1/gcc_64/bin/qmake and also 5.9.0 in /home/ubuntu/Qt/5.9/gcc_64/bin/qmake. At this point, I add a manual entry and locate the "qmake" executable from the ~/tk1/usr/bin/qmake. When I click OK, I'm presented with the following message:

"The qmake executable /home/ubuntu/tk1/usr/bin/qmake could not be added:" with no reason given as to why not. If I subsequently try to get the version of QMake within the /home/ubuntu/tk1/usr/bin folder using "qmake -v", an error pops up saying "/lib/ld-linux-armhf.so.3: No such file or directory"

And from this point, I'm a bit lost...

jsulm

@webzoid said in Qt and Jetson TK1 - Compiler Toolchain Setup Help:

apt-get install qt5-default

Well, you installed Qt for your host machine not your target device.
You need to cross-compile Qt for your target device, then you will have qmake for it which you then use in your kit. This qmake will be an x86 executable.
""The qmake executable /home/ubuntu/tk1/usr/bin/qmake could not be added:" with no reason given as to why not" - because this qmake is an ARM binary not x86. Your x86 host machine cannot execute ARM binaries. You need to cross-compile Qt.

webzoid

@jsulm I also performed "apt-get install qt5-default" on the TK1 prior to sync'ing the /usr/lib, /usr/bin, etc. Sorry, I completely forgot to mention this in my previous post.

jsulm

@webzoid As I said: you cannot execute binaries from your target device on your host. So, "apt-get install qt5-default" on the TK1 will not help as the qmake it installs is an ARM binary.

webzoid

@jsulm I appreciate that they won't execute due to architecture differences but given that I've sync'd the "TK1" binaries up to my Ubuntu host machine and pointed Qt towards them, isn't that the same as cross-compiling Qt as you suggested previously? Won't the result be the same - Qt which can execute on an ARM core? This may be what I'm missing or not understanding - sorry.

jsulm

@webzoid To cross compile your Qt app you need qmake, the qmake you have from your device cannot be used on your host. So, no it is not really same as cross compiling Qt. If you cross-compile Qt you will have qmake (and some other Qt tools) build for your host machine, but all Qt libs built for your target device.
This is how a Qt app using qmake is built:

qmake
make
make install (optional)

qmake must be the one from your Qt for target device, but it must be executable on your host.

webzoid

@jsulm I was just going to post this, until I saw your last reply.

My understanding (which is where I'm probably going wrong) is this:

The TK1 has Qt5 installed - which works. This TK1 installation contains all the binaries/libs/includes which allows applications to be compiled for the TK1. I can compile directly on the TK1 using QtCreator but don't want to do this.

All the toolchain on my host Ubuntu machine needs to do is to point to these binaries/libs/include files to generate code relevant to the ARM architecture. Is this not a fair assumption? Again, apologies if my lack of understanding is confusing things.

Ok, I think I understand now - so basically, I need a qmake binary which can execute on my Ubuntu host (for x86_64) BUT targets ARM architecture. For clarity, is this what you're saying?

I guess I was thinking that it'd be like GCC where I just specify the target architecture and libs I want to link it and it just works.

jsulm

@webzoid said in Qt and Jetson TK1 - Compiler Toolchain Setup Help:

Ok, I think I understand now - so basically, I need a qmake binary which can execute on my Ubuntu host (for x86_64) BUT targets ARM architecture. For clarity, is this what you're saying?

yes, that's correct.
You cannot use qmake from your host PC Qt installation as it is configured for x86 Qt set-up.

webzoid

@jsulm And I also can't use the one from the TK1 qt5-default installation as it is built for ARM and cannot be executed on my host

jsulm

@webzoid yes. That's why you usually cross-compile Qt for your target device.

webzoid

@jsulm Ok, thank you. I guess this is the step I was missing and not really understanding. Thank you for your help, I'll start Googling cross-compiling qmake...

webzoid

Somewhat more successful now.

I've been following the following instructions:

http://blog.qt.io/blog/2016/11/10/qt-nvidia-jetson-tx1-device-creation-style/

And have now successfully compiled and deployed qt5 onto my target and also set up qt creator to target the TK1. I ran into an issue whereby the target was complaining about the following:

/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.9' not found

but updating GCC/G++ on the target fixed this.

The final hurdle I need to get over is that when trying to launch my qt application (having been deployed from qt creator), I now get the following error and the application fails to launch:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.egldeviceintegration: Failed to load EGL device integration "eglfs_kms_egldevice"
EGL library doesn't support Emulator extensions

webzoid

Looking at the output from the ./configure script, it looks as though the EGL Device is not enabled...

Configure summary:

Building on: linux-g++ (x86_64, CPU features: mmx sse sse2)
Building for: devices/linux-jetson-tk1-g++ (arm, CPU features: neon)
Configuration: cross_compile use_gold_linker compile_examples enable_new_dtags largefile neon precompile_header shared rpath release c++11 c++14 c++1z concurrent dbus mremap reduce_exports stl
Build options:
  Mode ................................... release
  Optimize release build for size ........ no
  Building shared libraries .............. yes
  Using C++ standard ..................... C++1z
  Using gold linker ...................... yes
  Using new DTAGS ........................ yes
  Using precompiled headers .............. yes
  Using LTCG ............................. no
  Target compiler supports:
    NEON ................................. yes
  Build parts ............................ libs
Qt modules and options:
  Qt Concurrent .......................... yes
  Qt D-Bus ............................... yes
  Qt D-Bus directly linked to libdbus .... no
  Qt Gui ................................. yes
  Qt Network ............................. yes
  Qt Sql ................................. yes
  Qt Testlib ............................. yes
  Qt Widgets ............................. yes
  Qt Xml ................................. yes
Support enabled for:
  Using pkg-config ....................... yes
  QML debugging .......................... yes
  udev ................................... yes
  Using system zlib ...................... yes
Qt Core:
  DoubleConversion ....................... yes
    Using system DoubleConversion ........ no
  GLib ................................... no
  iconv .................................. yes
  ICU .................................... no
  Logging backends:
    journald ............................. no
    syslog ............................... no
    slog2 ................................ no
  Using system PCRE2 ..................... no
Qt Network:
  getaddrinfo() .......................... yes
  getifaddrs() ........................... yes
  IPv6 ifname ............................ yes
  libproxy ............................... no
  OpenSSL ................................ no
    Qt directly linked to OpenSSL ........ no
  SCTP ................................... no
  Use system proxies ..................... yes
Qt Gui:
  Accessibility .......................... yes
  FreeType ............................... yes
    Using system FreeType ................ yes
  HarfBuzz ............................... yes
    Using system HarfBuzz ................ no
  Fontconfig ............................. yes
  Image formats:
    GIF .................................. yes
    ICO .................................. yes
    JPEG ................................. yes
      Using system libjpeg ............... no
    PNG .................................. yes
      Using system libpng ................ yes
  EGL .................................... yes
  OpenVG ................................. no
  OpenGL:
    Desktop OpenGL ....................... no
    OpenGL ES 2.0 ........................ yes
    OpenGL ES 3.0 ........................ yes
    OpenGL ES 3.1 ........................ no
  Session Management ..................... yes
Features used by QPA backends:
  evdev .................................. yes
  libinput ............................... no
  INTEGRITY HID .......................... no
  mtdev .................................. no
  tslib .................................. no
  xkbcommon-evdev ........................ no
QPA backends:
  DirectFB ............................... no
  EGLFS .................................. yes
  EGLFS details:
    EGLFS i.Mx6 .......................... no
    EGLFS i.Mx6 Wayland .................. no
    EGLFS EGLDevice ...................... no
    EGLFS GBM ............................ no
    EGLFS Mali ........................... no
    EGLFS Raspberry Pi ................... no
    EGL on X11 ........................... no
  LinuxFB ................................ yes
  VNC .................................... yes
  Mir client ............................. no
  X11:
    Using system-provided XCB libraries .. yes
    EGL on X11 ........................... no
    Xinput2 .............................. yes
    XCB XKB .............................. yes
    XLib ................................. yes
    XCB render ........................... yes
    XCB GLX .............................. yes
    XCB Xlib ............................. no
    Using system-provided xkbcommon ...... no
Qt Widgets:
  GTK+ ................................... no
  Styles ................................. Fusion Windows
Qt PrintSupport:
  CUPS ................................... no
Qt Sql:
  DB2 (IBM) .............................. no
  InterBase .............................. no
  MySql .................................. no
  OCI (Oracle) ........................... no
  ODBC ................................... no
  PostgreSQL ............................. no
  SQLite2 ................................ no
  SQLite ................................. yes
    Using system provided SQLite ......... no
  TDS (Sybase) ........................... no

Note: Also available for Linux: linux-clang linux-icc

Note: Disabling Linux Accessibility Bridge: D-Bus is missing.

Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into '/home/blueprint/Desktop/TK1/qt5'.

Prior to reconfiguration, make sure you remove any leftovers from
the previous build.

jsulm

@webzoid Add -v parameter to your configure call then you will see what exactly is missing.

webzoid

@jsulm The -v parameter is already present, I added that from the beginning. It's not showing anything obvious or maybe I've mis-read the information. I'm trying it again now.

If I run a Qt application with the "-platform xcb" arguments, the application runs. If I add a QOpenGLWidget onto the form, the application fails with a:

QXcbIntegration: Cannot create platform OpenGL context, neither GLX or EGL are enabled.

Which would definitely make sense based on the build options from the ./configure script

jsulm

@webzoid There should be something - Qt is trying to build small code snippets to find out whether something is available or not.

webzoid

@jsulm I've attached the full output from the ./configure script to this email as it was too long to post on here: output.log

I've not managed to spot anything obvious in here.

Update I've since realised that the "-v" parameter was in the wrong place and I wasn't seeing a lot of the verbose output. I've since re-uploaded the ./configure output file.

jsulm

@webzoid

> eglfs-egldevice.cpp: In function ‘int main(int, char**)’:
> eglfs-egldevice.cpp:45:5: error: ‘EGLDeviceEXT’ was not declared in this scope
>      EGLDeviceEXT device = 0;
>      ^
> eglfs-egldevice.cpp:47:5: error: ‘EGLOutputLayerEXT’ was not declared in this scope
>      EGLOutputLayerEXT layer = 0;
>      ^
> eglfs-egldevice.cpp:48:12: error: ‘EGL_DRM_CRTC_EXT’ was not declared in this scope
>      return EGL_DRM_CRTC_EXT;
>             ^
> eglfs-egldevice.cpp:46:18: warning: unused variable ‘stream’ [-Wunused-variable]
>      EGLStreamKHR stream = 0;
>                   ^
> Makefile:467: recipe for target 'eglfs-egldevice.o' failed

My guess is your EGL version is too old.

webzoid

@jsulm Spotted those now too - sorry, the original file I looked through wasn't giving the true verbose output. Thank you for highlighting these.

Prior to starting the Qt cross-compilation, I downloaded (not installed) the libgles2-mesa-dev and libegl1-mesa-dev packages to my TK1 target and then extracted the relevant header files to the /usr/include directory. I then rsync'd this back up to my rootfs on the host.

I think as you say, the EGL version could be out of date.

Could this mean that I have to take a few steps back in Qt, rather than using 5.9, maybe head back to 5.5 or similar?

jsulm

@webzoid That I don't know. But you can try with an older Qt version.