Raspberry PI: A case study in deploying Qt apps to generic Linux devices

Published Thursday January 19th, 2012
13 Comments on Raspberry PI: A case study in deploying Qt apps to generic Linux devices
Posted in Embedded, Qt, Qt SDK, QtCreator


This is an awfully dry post; dry due to the sheer logistic nature of it. This functionality exists and is quite straight forwards to stumble upon. This blog exists in order to draw your attention to it and hopefully minimize the stumble time.

You have a device:

1) Running an ssh server
2) With gdbserver

You also have:

1) A functional tool chain for the target (Code Sourcery is the traditional goto)
2) A Qt build for your target
3) A Linux box you are deploying from (My convenience, instructions should be readily repurposeable for Mac based developers)
4) Qt Creator (Qt Creator 2.4.0 (as shipped with the QtSDK) was used at the time of filming/documenting this process)

Qt Creator has various merits which basically speak for themselves.

Integrated documentation
Convenient remote visual debugging/profiling
Convenient (single click) deployment

You grow accustomed to this functionality if you target any of the officially/unofficially supported targets tightly integrated into Creator in its various distributions. (Official SDK, Necessitas, Meego SDK). It would be lovely if it were more commonly perceived as a generic end to end solution for deployment to generic Linux targets, and it is readily achievable if you avoid a couple of snags.

Initial configuration

Launch Creator
Menu -> Tools -> Options

Build & Run -> Qt Versions

Add your Raspberry PI Qt build: /opt/dev/qt-qpa-5-rasp-pi/bin/qmake

Creator indicates “Qt version 5.0.0 for Desktop”, this can be safely ignored.

Build & Run -> Tool Chains

Add your cross compiler: /opt/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc

in my case. Adjust the ABI in the unlikely event it is incorrect.

Linux Devices -> Device Configurations

Add configuration with correct ssh details, deploy a public key and establish this works.

Per project configuration

1) Open an existing Qt application (example suffices)
2) Select a desktop build

Once this is done:

Projects -> Targets -> Build

Specify your target’s Qt version
Specify the toolchain from the drop down below

Projects -> Targets -> Run


Method: Deploy to Remote Linux Host
Device Configuration: Select your “Linux Device” added in the Device Configurations step above


Run Configuration: foo (on Remote Device)
Arguments: -platform eglfs

This should suffice, you should now be able to deploy, run and debug applications on the Raspberry PI (or any other similarly capable Linux based target)

A screen grab demonstrating the logistics is available here

A video where I talk through the steps is also available for those willing to weather my accent


1) If you select a QtQuick UI project from the project wizard you will not be able to deploy to the target (will be grayed out). If you select a Qt Quick application you will get a QDeclarativeView based viewer/launch pad. If you want to dabble with Qt 5 (who doesn’t) at present, one has to ride to war with one’s own QQuickView based runtime/viewer (read: pony)

2) Qt must already be deployed on the target. We clearly handle this for our own devices, but when you are winging it as documented here, Qt has to have been (manually) installed to the configured prefix. (Needless to say, it is best to sanity check the Qt install prior to attempting IDE based deployment).


Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Embedded, Qt, Qt SDK, QtCreator


Stef says:

Nice! Thanks you.

Qt4iOS says:

Just so you don’t end up hitting your head against a wall – there is a bug (reported, not fixed) in Qt Creator on Mac where it will fail to set itself up properly for cross-compiling. So, after you specify your platform’s qmake, you will need to go in to each project and add a -spec to the qmake command-line options. Otherwise it always assumes you’re building for a Mac host target, regardless of what your qmake is telling it.

Donald says:

@Qt4iOS: Shot bra, nice caveat

Very exciting work! Cant wait for my raspberry to arrive:)

Or for other generic boards which can be supported quite easily it seems.

Aymen says:

Qt 5 will not be available for Symbian^3?!!! whyyyyyyy?!!!! ๐Ÿ™
http://doc.qt.nokia.com/5.0-snapshot/supported-platforms.html (last line)

LS says:

@Aymen. I can’t wrap my head around that either. Not that I care, I don’t develop for Symbian, but what the heck is Nokia thinking?? First they say there will be 150 million devices running Symbian and Qt, and then the next version drops support with no warning? Doesn’t exactly inspire confidence in their ability to plan anything. Now they have all that effort for Qt Quick, and no supported mobile platforms.

I mean what the heck is the reasoning behind supporting Meego, which doesn’t run on a single commercially available device and never will, and NOT supporting Symbian, which still has millions of devices out there, and likely more coming?

h3nk3 says:

@Aymen, @LS. Could’nt agree more.

Can anyone from Nokia please comment on why this is. I have apps developed with Qt for Symbian and was looking forward to the speed improvements of QtQuick 2. Why Maemo and MeeGo is still supported before Symbian is really weird.

Rupert says:

@h3nk3: I doubt you are going to find qualified Nokia spokesmen trawling little trafficed blogs for completely out of context comment streams

This blog posting is about deployment to generic Linux targets from Creator, hijacking the comments will not shed light on a decision which was really implicit in the original Qt 5 blog posts. Basically, Linux is a first class citizen for mobile devices and few other mobile platforms are plausible candidates. You can give Meego grief for absence in the market, but at the end of the day it was very standards compliant (arguably too so, since it is just de facto desktop Linux with the exact same stack) and hence effectively “free” to support.

LS says:


Yes this is the wrong place to complain, for sure. But it speaks to the absolute failure to communicate on Nokia’s part that this frustration is being expressed here. Where is the official Nokia statement saying that Symbian is being dropped? Where is the explanation? Where is the workaround (maybe 4.8 will be supported in parallel for the long term?).

Many of the changes in 4.7 and 4.8 were specifically for Symbian and mobile, and then they completely neglect to mention that Symbian is being dropped in the next generation?

KNZ says:


please vote here for maintaining support of Qt Quick 2 for Symbian Belle/Carla Devices: https://bugreports.qt.nokia.com/browse/QTBUG-23856

h3nk3 says:

@KNZ, The “bug” got my vote!

@Rupert, Sure but it’s something that needs to be clarified and explained why. And I’m sure some Qt/Nokia guys are reading the comments and they can deliver our complaints to the right people. Hopefully.

Robert says:

Do you have any links explaining how to set up a different device for your pre-requirements?

“1) Running an ssh server
2) With gdbserver”

Donald says:


The Raspberry PI runs Debian:

apt-get install openssh-server

and you are golden. Similarly for gdbserver, you simply install it on the target device. Unless you are dealing with a broken Linux subsystem, Creator handles the process launching/handling.

True, for piece meal Linux systems (and they are the majority in the embedded space) you might need to fiddle with things. I would lead people towards either the Arch Linux or Gentoo wiki since those are my personal proverbial wise men in the generic Linux space.

Commenting closed.

Get started today with Qt Download now