Qt and Jetson TK1 - Compiler Toolchain Setup Help



  • I'd like any advice, if possible, with regards to setting up Qt for cross-compilation targetting the NVIDIA Jetson TK1. This is my first attempt at cross-compiling a Qt application so please excuse me if my questions are trivial.

    I have a couple of scenarios with which I'd appreciate some help:

    1. Qt creator is installed on the TK1 itself along with Qt 5.2.1.
      In the Kits setup, the sysroots path is empty and I'm unsure what to set this to. It would appear that in the /usr/bin folder are the relevant 'arm-linux-gnueabihf-' tools so would I point sysroots to this location?

    2. Qt creator is installed on an Ubuntu 16.04 host machine with Qt 5.9 and 5.2.1.
      As far as I am aware, in order to cross-compile for the TK1, I need to copy some directories from the Jetson TK1 onto my host machine and point Qt towards those. Is this correct?

    Thanks in advance.


  • Moderators

    @webzoid For case one you do not need any sysroot as you do not cross compile. Just set up compiler and Qt version correctly.
    Case 2: yes, you need a sysroot. A sysroot is basically your target device file system containing all needed header files and libraries. But sysroot alone is not enough: you need a cross compiler. A compiler running on your host but generating binaries for the target device.



  • @jsulm Thanks for your response.

    Scenario 2 is most important to me. As far as I understand, the arm-linux-gnueabihf compiler could be used as the cross-compiler? The sysroot would be the /lib and /usr/include directories? Would it be a case of copying these up to the host machine?

    Sorry again if my questions are basic. I've never done this before.


  • Moderators

    @webzoid If your target device uses an ARM processor, then yes it should be fine.
    You can copy needed parts of the target file system (retaining the file system hierarchy), or you can put the SDCard (if you use one for the target device) into your PC, or you can mount the target device file system using NFS.



  • @jsulm Yes, the target is an NVIDIA Tegra K1 ARM-A15 processor. It's probably easier if I copy the required directories up to the host rather than via microSD card, etc. Presumably, there would be no problem if I was to put the directories into a sub-directory for the target? Or do they need to live in the SAME directories as they would on the target for linkage purposes?


  • Moderators

    @webzoid No, you can put them in a subdirectory, you just need to retain the same directory structure inside that directory:

    SYSROOT_ROOT_DIR/
        usr/
            include/
            lib/
    ...
    


  • @jsulm Thanks, I'll give this a try shortly. I just didn't want to make a mess of the file system on the host before fully understanding what I was trying to achieve. Thanks for your help



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


  • Moderators

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



  • @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.


  • Moderators

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



  • @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.


  • Moderators

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



  • @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.


  • Moderators

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



  • @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


  • Moderators

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



  • @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...



  • 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
    


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

  • Moderators

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



  • @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


  • Moderators

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



  • @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.


  • Moderators

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



  • @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?


  • Moderators

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



  • @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



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


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.