Let's build small Qt libraries! (Step 2: Optimize build-settings)

Hedge · wrote on 17 May 2011, 15:14

I want to slim down my Qt-libraries a bit.
Therefore I downloaded the lateest source-package (qt-everywhere-opensource-src-4.7.3.tar.gz).

The first thing I wanted to do is build qconfig.exe

Therefore I run:

@Configure -release -opensource -no-exceptions -no-stl -no-opengl -no-openvg -no-libjpeg -no-libtiff -no-dsp -no-vcproj -no-webkit -no-scripttools -no-native-gestures
@

I have three questions for now:

qconfig can't find X11-related stuff. May I have excluded that when building the first time?
I've read about some useful gcc switches to reduce the size of the libraries

bq. -Os
-fmerge-all-constants
-fno-default-inline
-fno-inline

The instruction was to put them in the qmakespec-file. Where do I find that?

What does the switch -L mean when running configure? I've seen it a bunch of times

Peppy · wrote on 17 May 2011, 15:21

Use UPX for binaries "UPX":http://upx.sourceforge.net/
It means probably a library -lmath, -luser32, -lkernel32 etc...

Hedge · wrote on 17 May 2011, 15:22

I will use UPX -9, but that's the last step. For now it is building qconfig.

Peppy · wrote on 17 May 2011, 15:29

I've never used UPX for Qt Framework because I didn't have to...there are just big libraries for debugging (I think QtGuid.dll has around 140MB), for release, they don't have things for debugging so it spends much less space on your harddisk...

How much it spends in your computer?

Hedge · wrote on 17 May 2011, 15:31

With UPX -9 packed my tool (including all libraries) is around 9 MB in size (with the release-libraries)

I know we can smash it down further!

deni-herdiman · wrote on 17 May 2011, 15:36

hi,
i noticed upx not support PE+ or win64, might use mpress http://www.matcode.com/mpress.htm
it work like a charm.. :)

Hedge · wrote on 17 May 2011, 15:38

I will try mpress as well.

To get qconfig compiled I will build the whole Qt Suite again with some exceptions (-nomake examples -nomake demos).

Peppy · wrote on 17 May 2011, 15:39

9MB is too much?

I suppose you do it for school. In that way, I think you should use "static" release, it adds Qt Framework Libraries into your project libraries, so you won't have to carry Qt DLLs with project, but it will have to effect on size of your binaries, after that you should use UPX....

Hedge · wrote on 17 May 2011, 16:05

I've already programmed this tool twice (in Object Pascal and C#). The tool was always around 2-3 MB in size.

I don't want to scare my users off and am generally interested in this whole build-improvement thing.

Binding it statically won't reduce the size much (and isn't allowed in that context either if I go LGPGL).

@Peppy: I will try the MSVC-compiler as well.

goetz · wrote on 17 May 2011, 17:13

As you're on Windows using MinGW (I know your project quite good now :-) ) you must add the respective mkspec:

@
./configure -platform win32-gcc ... your additional args go here ....
@

The rest of your no-xxx switches does not influence the size very significantly. It just leaves out the build of some submodules and the like, which you would not put into your final applications directory anyways.

Be sure to create release libs (without debugging symbols), this decreases the size of the libs significantly!

And finally you can try to run MinGW/bin/strip.exe on every executable and library (DLL) you have in your directory. I did not try this yet, but at least on Unix this reduces the size even more.

For distribution, put it all in a ZIP. UPX and the like is not really useful IMHO. The exe and the libs must be decompressed eventually to run the program, thus slowing down the start up time of your application.

Remember: Disk space is cheap :-)

Peppy · wrote on 17 May 2011, 17:26

@Volker: I thought so. But I am very surpised that somebody wants to compress binaries on the maximum in time when we have 2-3 TBytes harddisks (no everybody has terabytes harddrives, but 16MB is not so much...)...

I am compiling under MSVC 2008 compiler and it's quite better than MinGW (IMHO)...

BTW. What is the name of your project? :-)

Hedge · wrote on 17 May 2011, 17:35

bq. As you’re on Windows using MinGW (I know your project quite good now :-) ) you must add the respective mkspec:
./configure -platform win32-gcc ... your additional args go here ....

Just making sure. So I need to attach the compiler-switches like -fmerge-all-constants already in the configure-step?

These are the Qt-dll's and their sizes my program currently needs:

@Uncompressed size | UPX -9 size | Name

  2,43MB          |    0,91MB    | QTCore4.dll
  2,92MB          |    0,86MB    | QTDeclarative4.dll
  9,39MB          |    3,69MB    | QtGui4.dll
  1,15MB          |    0,40MB    | QTNetwork4.dll
  2,07MB          |    0,65MB    | QTScript4.dll
  0,20MB          |    0,10MB    | QTSql4.dll
  3,82MB          |    0,94MB    | QTXmlPatterns4.dll

 21,98MB              7,55MB@

Especially QtGui4.dll should be reducable much further since I'm using exclusively QML (with Jens desktop-components) for the GUI.

Peppy · wrote on 17 May 2011, 17:42

Quite big difference...but there is a good question: Do you need it? Will it help you as you are waiting? Has the binary compression any result on booting (I mean loading) time?

goetz · wrote on 17 May 2011, 17:50

The DLLs cannot be shrunk, unfortunately. They contain all the symbols of the module, even if you only need one of them. And QML of course depends heavily on the widgets in QtGui :-)

Peppy · wrote on 17 May 2011, 17:54

DLLs should get redesigned, this system is too old (from Windows 95, I think), but that's the work of Microsoft...

Hedge · wrote on 17 May 2011, 17:55

So even qconfig won't help?
I could exclude some widgets in the sourcecode but that is a bit too much (imagine I need to do this for every new qt-version).

strip <file> -s didn't really do much. Any other useful parameters?

What I am aiming for is a small download-size for users.

Peppy · wrote on 17 May 2011, 17:56

-o1, ..., -o5 for MinGW

Hedge · wrote on 17 May 2011, 18:01

Where do I use these flags?

I initially asked where I can apply the compiler-flags:

bq. -Os
-fmerge-all-constants
-fno-default-inline
-fno-inline

Neither configure nor mingw32-make accept them.

goetz · wrote on 17 May 2011, 18:01

[quote author="Peppy" date="1305654867"]DLLs should get redesigned, this system is too old (from Windows 95, I think), but that's the work of Microsoft...[/quote]

Shared libraries (.so on unix/linux, .dylib on Macs) behave just the same way! They were intended to reduce the memory footprint (a shared library is loaded into memory only once and used by multiple programs), as well as disk space. Both are not so an issue anymore these days.

So, a Mac application bundle is "bloated" too, as would be a linux archive containing all necessary non-system libraries.

goetz · wrote on 17 May 2011, 18:10

[quote author="Hedge" date="1305654933"]So even qconfig won't help?
I could exclude some widgets in the sourcecode but that is a bit too much (imagine I need to do this for every new qt-version).

strip <file> -s didn't really do much. Any other useful parameters?

What I am aiming for is a small download-size for users.[/quote]

No, qconfig does not help. The DLLs will always contain all widgets.

strip regularly does not save very much space on binaries compiled in release mode already.

If you're only after a small download size, use a decent archiver and set it's mode to maximum compression.

[quote author="Hedge" date="1305655290"]Where do I use these flags?

I initially asked where I can apply the compiler-flags:

bq. -Os
-fmerge-all-constants
-fno-default-inline
-fno-inline

Neither configure nor mingw32-make accept them.[/quote]

These are compiler/linker flags, you can try to set them for configure this way:

@
CFLAGS="-Os -fmerge-all-constants -fno-default-inline -fno-inline"
./configure -platform win32-g++
your additional flags go here
@

But be aware that fiddling with optimization settings (-Os) may make things worse or add a runtime slowdown penalty.