[Qt-interest] LGPL and static linking

Thiago Macieira thiago at kde.org
Tue Dec 1 18:46:36 CET 2009


Em Terça-feira 01 Dezembro 2009, às 15:54:35, Paul Floyd escreveu:
> 1) Size [files and memory footprint]. The statically linked app only
>  extacts those functions and data that it requires from static libraries,
>  whilst dynamic libraries have to keep everything. When you have more than
>  one application using the library/ies, then dynamic linking can have an
>  advantage. Additionally, linking options like lazyload can reduce the
>  memory footprint.
> 
> 2) Speed. Dynamic libs get compiled with position independent code (pic).
>  This is generally slower, as global data and functions need to 'bounce'
>  off an offset. Code in static libs can access globals and call functions
>  directly.

Both arguments are true. However, let me expand on them:

1) Qt classes are very interdependent on their own. That's why a static binary 
is huge. Even if you don't use some feature and it's in no way called in your 
code, just because one Qt class can interact with another, it's compiled in.

An example is QFtp. Suppose you don't use it or FTP at all. But you use 
QNetworkAccessManager (directly or via QtWebKit). Since QNetworkAccessManager 
by can use QFtp if you pass an ftp:// URL, QFtp will be compiled in and will 
be present in your executable.

The only way to avoid that is to use qconfig and depopulate Qt of the features 
you don't use. Please note that we in no way test those configurations. If it 
fails to build, let us know by sending a patch with the fix.

2) dynamic libraries contain pure text pages as well as pure read-only data 
because of the Position Independent Code. This means the text pages can be 
loaded directly off the disk and discarded whenever there's memory pressure. 
There's no swap consumption for them.

Static libraries and applications themselves, however, have impure text. A 
good example of this is NVidia's libGLcore.so on Linux: it's not built with -
fPIC (they argue speed issues because they lose one register). That means 
*EACH* application that uses OpenGL when NVidia's libraries are installed 
consumes 10 MB of RAM, non-shared. Since these pages are not pure, if there's 
memory pressure, they have to be swapped out (to the system memory swap), 
instead of simply discarded.

So I would recommend always building with -fPIC. You lose one register on x86, 
no registers on x86-64 (addressing is IP-relative). In addition, using -
fvisibility=hidden -Wl,-Bsymbolic-functions allows you to reduce the number of 
symbols that need resolving the symbol table or by name. This reduction is not 
100% though, so there will be a slight performance impact due to loading some 
variables indirectly.

Note: this doesn't apply to Windows: there's no PIC on Windows.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091201/e33558d3/attachment.bin 


More information about the Qt-interest-old mailing list