Qt and Jetson TK1 - Compiler Toolchain Setup Help

[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.

[webzoid]

@jsulm I'm possibly going round in circles now.

There appeared to be no newer version of EGL to download for the TK1 however I did notice a number of other packages related to EGL:

sudo apt-cache search libegl

libegl1-mesa - free implementation of the EGL API -- runtime
libegl1-mesa-dbg - free implementation of the EGL API -- debugging symbols
libegl1-mesa-dev - free implementation of the EGL API -- development files
libegl1-mesa-drivers - free implementation of the EGL API -- hardware drivers
libegl1-mesa-drivers-dbg - free implementation of the EGL API -- driver debugging symbols
libegl1-mesa-dev-lts-utopic - free implementation of the EGL API -- development files
libegl1-mesa-dev-lts-vivid - free implementation of the EGL API -- development files
libegl1-mesa-dev-lts-wily - free implementation of the EGL API -- development files
libegl1-mesa-dev-lts-xenial - free implementation of the EGL API -- development files
libegl1-mesa-drivers-lts-utopic - free implementation of the EGL API -- hardware drivers
libegl1-mesa-drivers-lts-utopic-dbg - free implementation of the EGL API -- driver debugging symbols
libegl1-mesa-lts-utopic - free implementation of the EGL API -- runtime
libegl1-mesa-lts-utopic-dbg - free implementation of the EGL API -- debugging symbols
libegl1-mesa-lts-vivid - free implementation of the EGL API -- runtime
libegl1-mesa-lts-vivid-dbg - free implementation of the EGL API -- debugging symbols
libegl1-mesa-lts-wily - free implementation of the EGL API -- runtime
libegl1-mesa-lts-wily-dbg - free implementation of the EGL API -- debugging symbols
libegl1-mesa-lts-xenial - free implementation of the EGL API -- runtime

What with the TK1 running Ubuntu 14.04, none of the additional packages seemed relevant but I decided to download one of the xenial packages to see if there was anything EGLDeviceEXT related in the header files. As it turns out, the xenial package does indeed contain an eglext.h file containing such a definition.

So, I copied the headers to the /usr/include of the TK1 and then rsync'd them back up to the host. After re-running ./configure (again, with less verbose output, even though the -v is present from before) and pushing the Qt build down to the TK1, I still have the same ultimate outcome when trying to run the application:

Failed to load EGL device integration "eglfs_kms_egldevice"
EGL library doesn't support Emulator extensions
Aborted

If I then run with -platform xcb arguments, all runs fine.

Looking at the following article, the "ideal setup" shows that EGL, OpenGL ES 2.0, 3.0 and 3.1 are set to "yes" as well as EGLFS and EGLFS EGLDevice. On my TK1, I have EGL, OpenGL 2.0, 3.0 but NOT 3.1, EGLFS is set to "yes" but EGLFS EGLDevice is set to "no".

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

If I then try to add a QOpenGLWidget while keeping the -platform xcb arguments, it doesn't work at all - resulting in the same QXcbIntegration: Cannot create platform OpenGL context, neither GLX or EGL are enabled.

In a word, aaaaaarrrrgggghhhh

I've attempted to cross-compile older versions of Qt (from 5.6 upwards - older versions have no mkspec for the TK1) but the problems are the same

[webzoid]

Ok, I've since taken a step back and had a cup of tea.

I had a search for additional packages which may have sounded useful and I came up with the following: libx11-xcb-dev and libxext-dev. Downloaded them both and copied the header files/directories to /usr/include. I then ran a make clean on the qtbase directory before re-attempting to reconfigure.

When I did eventually do a ./configure, I noticed that the EGL for X11 suddenly had a bit, fat YES next to it, along with a number of other XCB options which were previously NO.

Having run make and make install and then deployed the qt5 target folder to the TK1, I can now say that everything just works!

Thank you @jsulm for your help with this.