[Qt-interest] LGPL and static linking

Jeroen De Wachter jeroen.dewachter at barco.com
Thu Nov 26 11:20:36 CET 2009


Hi,

The main reason we want to link our application statically is disk
space. We are working on an embedded platform where this is very much an
issue.

However, we will very likely soon have a second Qt-enabled application
running on our device so the advantage of static linking with regard to
size is much reduced (it doesn't help much to have the same Qt code in
each binary if it could just as well be shared in a .so file)

You can still save some space, however, by removing any functions not
used by any program. The mklibs package should be able to do just that.
The package is in the debian and ubuntu repositories, but I have not
been able to find out who's actually developing it...
Also note we have not yet tested it, so no guarantees there.

Kind regards,

Jeroen

On Thu, 2009-11-26 at 07:44 +0100, Stefan Josefsson wrote:
> 
> Hi Frank and all others that has been trying to give me an answer so
> far! 
> 
> I have spent many days in trying to configure Qt and also to find the
> right compiler switches to use. I end up with a statically linked exe
> file that is 16 MB. I have then: 
> - Used qconfig to strip away things that I do not need. 
> - Used compiler optimization. 
> - Compiled so that unused code is not included in the exe file (btw,
> this is only possible when linking statically which is one of the
> reasons of why statical linking is preferable). 
> - Stripped the binary. 
> 
> The statically linked application starts in less than a second on my
> target while the corresponding dynamically linked application needs
> about 10 seconds. One way to improve the startup time for the
> dynamically linked application would probably be to use "prelinking",
> but then again there may be some issues with the LGPL license as a
> prelinker makes it impossible to exchange the shared library. 
> 
> Thanks, 
> Stefan 
> 
> 
> 
> 
> On Linux there's a great tool called chrpath, which lets you
> edit the rpath and runpath of your binary (check out the Debian
> package
> repros), which lets you safely forget about LD_LIBRARY_PATH.
> (I'm telling everybody who whines about dynamic linking;)
> 
> Secondly I can't buy that you have issues with load times of dynamic
> Qt
> libs. If taking the configure flags carefully when building Qt it will
> pop up like nothing, even if loaded dynamically from a cheap flash.
> ld performance bugs have been fixed years ago!
> Currently my Qt 4.5.2 is at 20 MB for QtCore + QtGui and it starts
> in about a second or less (can't tell) on a class 6 SD card.
> 
> Maybe there is a problem with call indirection when using DSO's
> instead
> of static linking. For me there is about a 30% performance gain
> if linking my own libs statically and nobody keeps me from doing so,
> even if Qt is linked dynamically.
> 
> Cheers,
> Frank.
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest


DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.





More information about the Qt-interest-old mailing list