[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