Unclear about configure options.
-
Am trying to cross-compile QT libraries to be used on a LINUX embedded platform. What I would like to achieve is this:
- Cross-compile QT for the target platform and accumulate all the libraries that any QT application would need, so I can deploy the same on the target platform.
- Cross-compile QT for the target platform and accumulate all the libraries and include files that can be used by applications to compile and link against.
The result of step 1 will become part of the image for the embedded device, if you get the idea.
To achieve this, am not sure what options I should use for configure. For convenience, I have posted the available options that I get when I try ./configure -embedded -help. Am not sure if each one is mutually exclusive, or, if I can combine them etc.
Here is what the ./configure -embedded -help shows:
These are optional, but you may specify install directories.
-prefix <dir> ...... This will install everything relative to <dir> (default /usr/local/Trolltech/QtEmbedded-4.7.2) -hostprefix [dir] .. Tools and libraries needed when developing applications are installed in [dir]. If [dir] is not given, the current build directory will be used.- -prefix-install .... Force a sandboxed "local" installation of
Qt. This will install into
/usr/local/Trolltech/QtEmbedded-4.7.2, if this option is
disabled then some platforms will attempt a
"system" install by placing default values to
be placed in a system location other than
PREFIX.
Any help, with examples, will be really appreciated.
Thanks in advance!!
-
Take a look at this "wiki article":http://developer.qt.nokia.com/wiki/Qt_for_Embedded_Linux
-
Thank you very much for the reply. Will look up in the article.
-
Thanks for the assistance. I am in need of another clarification.
There are all these options we can specify with ./configure ( e.g. -dbus, -stl ) as specified here:
http://doc.qt.nokia.com/4.7-snapshot/configure-options.html
There is also this document here about something called qconfig:
http://doc.qt.nokia.com/latest/fine-tuning-features.html
So, are these ways to turning on/off features mutually exclusive? i.e. if we specify -qconfig in the ./configure command line, we should not specify anything else related to the features in the same command line?
Also, the same fine tuning document refers to what are -no-feature-{something} options, which the first document does not talk about.
Am I the only one to be confused?
-
As a rule of thumb, start out simple and then change things a little at a time if you find you need a feature or really want to remove a feature.
Using the qconfig tool can be dangerous. It does not enforce dependencies between features (as far as I am aware) so you can easily shoot yourself in the foot. If you do choose to use the qconfig tool then you have to pass in the created config file to the Qt configure tool like this:
@./configure -qconfig myfile@
where myfile is the saved output from qconfig.
In any case it is unlikely that your embedded app will use all the facilities of Qt and so you can get away with deploying only a subset of the QT libs to your target device. For example if you do not use the QtSql module in your app there is no need to copy across libQtSql.so to your device.
I woudl suggest to get your app working using only a basic configure command first and only then consider using the qconfig tool if you find that you are severely space constrained on your target device.
-
I did start out simple and the basic configuration works well. But, I really need the size down, since I work in an environment with limited resources, so I have a real need to strip whatever is unnecessary.
I had a bit of trouble with the documentation so far. The -fast, from what I read, was intended to leave out compiling the demos and examples, if I read right. But that didn't work. Then, I read up somewhere about -nomake demos and -nomake examples. I tried those options, and they do work right. What baffles me is the configure documentation makes no mention about these flags. It's frustrating and dangerous to be trying out things that are not really documented.
-
I agree that the help for the configure script is missing some stuff and is not the clearest. If you find shortcomings and want to help fix them for others you can do so by getting yourself an account at "gitorious":http://qt.gitorious.org and submitting a merge request for your changes.
For info the -fast option just makes the initial configuration stage faster because it only generates the top-level Makefiles rather than Makefiles for all the sub-dirs. The sub-dir Makefiles get generated during the actual compilation stage by special rules that call qmake first in each sub-dir.
What modules do you definitely need? What features within them are you using? What are your space constraints?
-
Hi ZapB,
appreciate your helpful answers. With your help, am slowly able to get around some of the confusions. I'll look into registering with gitorious, thanks for the tip.
The -fast option is clear now. For my production build I'll use the -nomake demos and -nomake examples options, because I have no need for them.
I have a simple UI, mostly text and a few indicators and icons on the screen. That's about it. No need for fancy windowing stuff and things like that. So , QWidget , QLayout stuff, XML handling ,keyboard and graphic handling is all am after. No need for all the fancy dialog stuff.
Ideally I would like to have the binary size less than 1.5 - 2 MB. Right now, it is coming at around 13 MB which seems a too much.
This is all the ./configure options am using:
-embedded arm
-static
-release
-fast
-nomake demos
-nomake examples
-no-largefile
-no-accessibility
-no-stl
-system-sqlite
-no-qt3support
-no-xmlpatterns
-no-multimedia
-no-audio-backend
-no-phonon
-no-phonon-backend
-no-svg
-no-webkit
-no-javascript-jit
-no-script
-no-scripttools
-no-declarative
-no-declarative-debug
-system-zlib
-no-libtiff
-no-libmng
-no-openssl
-no-nis
-no-cups
-no-opengl
-no-gfx-transformed
-no-gfx-qvfb
-no-gfx-vnc
-no-gfx-multiscreen
-no-gfx-directfb
-no-gfx-qnx
-no-kbd-tty
-no-kbd-qvfb
-no-kbd-qnx
-no-mouse-pc
-no-mouse-linuxtp
-no-mouse-linuxinput
-no-mouse-tslib
-no-mouse-qvfb
-no-mouse-qnx \Is a 2 MB size too optimistic a size ?
-
I will have to try a small build myself as I can't recall what size I got the build down to before.
In the meantime, another option you should consider is that of building Qt as a static library. That way at link time, the linker will only include the parts of Qt that you are actually calling. As a side benefit it also removes the relocations performed by the runtime linker at application startup so your app will start faster.
-
IANAL but I was under the impression that you could use a static build under the LGPL license as long as you provide a way of relinking your app with a newer version of Qt. Not saying that it is easy. And for all I know the OP could be using a commercial license. Are you?
-
[quote author="ZapB" date="1302079470"]IANAL but I was under the impression that you could use a static build under the LGPL license as long as you provide a way of relinking your app with a newer version of Qt. Not saying that it is easy.[/quote]
I share that vision, but IANAL either. -
Thanks for the replies all. I wasn't aware of the shared versus static complication. So appreciate your bringing it up. I don't have any idea of the legal issues, so will leave it to the respective guys to figure it out. At the moment, I would at least like to have both static and shared linking options figured out and have a feel of the minimum sizes I can get in each case. Those numbers might also drive what licensing options we might consider. Since there is just one QT app running on our device, there is really no "need" for the shared option, except if that need is enforced upon by the licensing restrictions.