[Development] Use static qt libraries

marius.storm-olsen at nokia.com marius.storm-olsen at nokia.com
Tue Jul 24 19:24:51 CEST 2012


On 07/24/2012 09:26 AM, ext marius.storm-olsen at nokia.com wrote:
> So, I actually gave it a go on my Linux box to see how the numbers would
> turn out. Here's what I got:
>
> Build configuration: ./configure -shared -release -opensource
> -confirm-license
> Normal shared split libraries:
>     libQtCore.so.5.0.0: 4437 relocations, 3600 relative (81%), 232 PLT
> entries, 232 for local syms (100%), 0 users
>     libQtGui.so.5.0.0: 6518 relocations, 4703 relative (72%), 718 PLT
> entries, 718 for local syms (100%), 0 users
>     libQtNetwork.so.5.0.0: 2492 relocations, 1429 relative (57%), 598 PLT
> entries, 598 for local syms (100%), 0 users
>     libQtWidgets.so.5.0.0: 19702 relocations, 15205 relative (77%), 1899
> PLT entries, 1899 for local syms (100%), 0 users
>                      (Sum: 33149 relocations, 24937 relative (75%))
>
> Normal shared monolithic library (using core, gui, network and widgets):
>     libQtMassive.so: 32978 relocations, 28359 relative (85%), 380 PLT
> entries, 380 for local syms (100%), 0 users
>
>
> Build configuration: ./configure -static -release -opensource
> -confirm-license
> Static compile to shared monolithic library:
>     libQtStatic.so: 32032 relocations, 30428 relative (94%), 402 PLT
> entries, 402 for local syms (100%), 0 users

Also, when looking at symbols created you'll see that the static-based 
version will use symbols like
     abort
     accept
while the shared-based version uses
     abort@@GLIBC_2.2.5
     abort at GLIBC_2.2.5
     accept4@@GLIBC_2.10
     accept4 at GLIBC_2.10

(See the full listing here: http://pastebin.com/nEvzpzAk )

If you ignore library "tags" and just look at the functions, you still 
get differences, such as
     adjustFtpPath(QUrl)
     (anonymous namespace)::intersectPath(QPainterPath const&, QRectF 
const&)
     QForeachContainer<QStringList>::QForeachContainer(QStringList const&)
being present in the static-based one and not in the shared-base lib, 
while the shared-based one has functions like
     QDateTimeParser::StateNode::~StateNode()
     QForeachContainer<QStringList const>::QForeachContainer(QStringList 
const&)
     qt_string_count(QChar const*, int, QChar const*, int, 
Qt::CaseSensitivity)
which are not in the static-based libe.

(See the full listing here: http://pastebin.com/5n0vdT2V )

So, be aware of the differences between the two ways of creating the 
monolithic library.

I still insist that using the "massive.pro" approach is the correct way 
to go about it, and I've attached the change needed to bring core, gui, 
widgets and network together to one massive library.

It's not "clean", but it would certainly be possible to fix up the 
modules to make massive builds easier.

If you apply this patch ontop of current qtbase#master, you can
     cd <qt5/qtbase>
     ./configure -shared -release -opensource -confirm-license
     cd src
     make -j <n>     # Just to easily build all the tools etc
     cd massive
     make -j <n>
and you'll have libQtMassive.so in <qtbase>/lib. Note that this patch 
has not altered the build system so that using core, network, gui and/or 
widgets will use the massive library, but at least you're able to build 
examples using
     QT += massive
with it.

-- 
.marius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Do-a-massive-build-with-core-network-gui-and-widgets.patch
Type: text/x-patch
Size: 138477 bytes
Desc: 0001-Do-a-massive-build-with-core-network-gui-and-widgets.patch
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120724/3a95401b/attachment.bin>


More information about the Development mailing list