Installing Qt framework on embedded Linux
Alicemirror last edited by
Hi to all,
I have a working linux environment on ARM created with Ltib toolchaing and based on LPC3250 cpu. At the moment the embedded platform works fine, connect to the net and manage all its devices. The board includes a framebuffer device + tochscreen, the Linux running on the board was built excluding X11 server, with the native hardware Framebuffer components.
By the other side, I finally finished to build a complete Qt embedded linux platform, on the same desktop. All the library and some examples were built with the same GCC compiler with the arm5 option so I have a Qt framework compiled for the Arm cpu.
The - simple - question is to know exactly where are the compiled libraries in the Qt for embedded environment, that I will install in the linux embedded platform in a system library folder of somewhere else including the path to the system folder to test what works and what is wrong to proceed with fine tuning and debugging.
Thank you for all advices.
Hey Alicemirror. To install Qt onto your device you obviously need to find where you cross-compiled Qt to on your host system - ie the prefix that you specified to the Qt configure script. Once you have that location, then cd to its parent directory and simply rsync across the parts of Qt that you need (likely to be QtCore, QtGUI, QtNetwork plus whatever other modules you are using).
I recommend using rsync to copy the libs across as rsync supports preserving symlinks whereas scp does not.
There is one subtlety you have to watch for when deploying Qt to your target device and that Qt needs to be able to find the fonts dir that is a subdir of the Qt lib dir (iirc). I think that there is some environment variable that you can set to tell Qt whre to look for the fonts dir - I can't recall what it is offhand though so I'll look a little later.
Another approach that works though is to use the fact that Qt looks in the directory structure to which it was installed on your host machine (/usr/local/qt-embedded) say. So what you can do is simply replicate this directory structure on your target device and use a symlink to point at the actual location of where you deployed Qt to.
For example, say you deployed Qt to /opt/qt-embedded on your device, but you built and installed it to /usr/local/qt-embedded on your host machine, then on your target machine do:
mkdir -p /usr/local/qt-embedded/lib
ln -s /opt/qt-embedded/lib/fonts /usr/local/qt-embedded/lib/fonts
With the above, Qt will look into the path it has compiled in (/usr/local/qt-embedded/lib/fonts) and will be able to find the necessary font files.
Once you copy your application across to somewhere suitable (which is up to you but could be /usr/local/bin or /opt for e.g.) and you set LD_LIBRARY_PATH (or even better add entries to the system wide dynamic linker configuration, /etc/ld.conf iirc) so that the linker can find Qt, then you are ready to go. Just remember to launch with the -qws command line option.
You may need to set some other environment variables to tell Qt which framebuffer device to use etc.
Hope this helps. Feel free to come back if you have any problems with it.
Alicemirror last edited by
Hey Zapb, many thanks for this answer. Yes, it is very useful. I am not a newbie in e,bedded linux platforms, but I am totally new to the graphic approach with Qt.
I read - and little confused - the documentation on how to install. I was thinking to something like you explained, but not so clearly and precise. This informations are essential because if something goes wrong I can be almost sure that the problem resides in my application.
As a matter of fact I have compiled leaving the configuration with all the possible defaults so my Qt installation is under /usr/local/Trolltech/Qt-embedded-4.7.2-arm
You mention rsync to transfer data to the device, but in my case I am using an embedded platform with ltib and I am not sure that I can include the rsync application in the kernel at all. Atcually I am using tftp between the embedded and the linux pc to download the components and I already saw that it doesn't support symlinks. To be honest, symlinks are converted in the files themselves, resulting a little trouble. If I can setup rsync on the embedded platform, tjis is the best way else I copy the .so files only from the lib folder and create locally the symlinks using a script.
Another think i was not sure, is about the other things that are created under the target on my host computer (/usr/local etc.) are them needed in someway or I need only the libraries and plugins? What is the approach t follow to install the plugins needed by the application (those part of the Qt framework) ? Deploying applications for the desktop, plugins are set in. Directory of the application package, but in this case what should be done, if there is a method?
Justo to complete the list of my doubt, I have not so clear how it works the virtual framebuffer. In the embedded platforms with toolchains I know like ltib or openwrt, it is strongly recommended to use the virtual framebuffer only for debuggind purposes because it generate a real slowdown in the application. In this case it is the same or the vfb can be used to see remotely what's happens on the framebuffer? In the Qt for embedded documentation I ad that the vfb need a x11 server to support it, but it is not clear if this means that you should run the application on the host computer with a x11 ser er qworking (just like a linux desktop) or the x11 sver should run on the embedded device to have the vfb working on the host?
Last, an O.T. Small question. Do you read my update on the group Qt embedded proposing to open a wiki in the group to share specific situations only related to embedded platforms non-mobile related? What do you think about?
Bye, many thanks again
Rsync should be relatively easy to cross-compile but having said that why bother if you already have a means of transferring to your device. Whatever works with minimum hassle ;-)
You only need to deploy the plugins that you are actually using. Whether you deploy them beside the Qt libs or within your application dir is entirely up to you. If you have >1 app using them then I would just put single copy of the plugins in next to the libs just like linux distros do.
Right as for the framebuffer, virtual framebuffer, X11 etc... Here is how they compare:
The qvfb program (which is part of your desktop X11 build of Qt) runs on your desktop and acts as a virtual framebuffer device. It has options to set whatever resolution you like and also has a skinning ability so that it can look like your actual device. This is very useful for testing your app when it is built against your host Qt-embedded build of Qt. In fact you have to do it this way since Qt Embedded knows nothing of X11. Think of qvfb as a kind of windowed simulator within which your app and host build of Qt Embedded runs. The only place X11 comes into this is that qvfb is an application that runs on your host machine and so requires X11 on the host.
The framebuffer device is the real device equivalent of qvfb when running on your actual device. It usually has a device name such as /dev/fb0. Check that you have sufficient permissions to read and write to this device. If you are running your app as root then you shudl be fine.
Another option for debugging your app (either on your device or using your embedded host build) is to export the display via VNC. With this option, your app acts as a VNC server to which you can connect any VNC client. This makes it possible to run your app on the device but to interact with it using your host machine (or any other machine to which it is attached on the network).
Finally, you can export the display to both the framebuffer and VNC if you like.
I'll add some more detailed notes on how to do these things on the wiki next week when I am back at work.
NickGlynn last edited by
With regards to the font settings. I had a look and, if you're using QWS, you can set the variable QT_QWS_FONTDIR to point to the correct location e.g.
Hope that helps.
Ah yes that's it. I knew I'd seen something like that somewhere but could not find it. Thanks for reminding me.