How can I make my program 'weight' less

[kshegunov]

@roseicollis said:
Aside from compiling your libraries and then linking as shared objects (.so), no, not really. In principle this would be my first choice anyway, I don't see much use of static libraries (except for some very special cases).

[roseicollis]

@kshegunov I'm kinda new with all that about using third libraries so I just searched and found this way of using them as my mate (the one who compile them) generates the .a file.

Then you think I should do the link in another way? Will it decrease the weight of my file? (I'll google what's that you said about shared objects in a while )

EDIT: I've see what it is... as I've found (an easy explanation):

A static library(.a) is a library that can be linked directly into the final executable produced by the linker, it is contained in it and there is no need to have the library into the system where the executable will be deployed.

A shared library(.so) is a library that is linked but not embedded in the final executable, so will be loaded when the executable is launched and need to be present in the system where the executable is deployed.

So my question is, if my mate generates that .so files... would I have a less-weight exe? And how can I link them, should I do it like I did with the .a but changing the .a for a .so (if the final name of the lib is the same just changing the extension)? Ofc I understand that the .so libraries will have to be where the program runs (in the hardware).

[kshegunov]

@roseicollis
Yes, if you use a dynamic library (on linux/*nix called shared object, hence the extension) your executable will be smaller. The .so files are searched for and loaded at runtime (performed by the loader) and symbol linkage is performed at runtime as well (not true for windows, where the linker requires a special .lib file). The shared object's location should be known to the loader:

1. You either have to put the library in the system folder allocated for that (/usr/lib/ for most linux distributions)
2. or you set the library path through the LD_LIBRARY_PATH system variable
3. or you set the rpath variable at compile time (that one is included in the final binary image)

Each of the three options has its values, depending on what exactly you're trying to achieve. Usually if you use the library for a single application you go with option 2 or 3. If there are multiple executables using the same library you go with either 1 or 3.
As for the linkage, yes you link static and dynamic libraries in qmake the same - by using the LIBS variable and passing them with the -l switch. For dynamic libraries the line unix:!macx: PRE_TARGETDEPS += $PWD/../../Libs/Release/Lib1.a should not be used.

[roseicollis]

@kshegunov
Thank you so much for the explanation. I know now all the options and when to use every one. It's a really interesting post :). About the last line that you said I shouldn't use... I don't really know what does the 4 lines I used to include the libs (I just searched on internet and tried until it worked) but I suppose that its something like:

• unix:!macx: LIBS += -L$PWD/../../ConfigLib/Release/ -lLib1: this one defines the library
• INCLUDEPATH += $PWD/../../Lib1: this is the path
• DEPENDPATH += $PWD/../../Libs/Release: this should be the path of another lib needed because of dependency
• unix:!macx: PRE_TARGETDEPS += $PWD/../../Libs/Release/Lib1.a: And this one... I don't really know unless it needs the exact path and name+extension of the lib.

That aside, this will not help me with my problem sadly. I've asked my mate and told me that all the applications in our product use static linkage with the libraries (because ofc they don't want to add those libs on the product) so... I'll have to keep the static linkage.
Until now, the stadistics of the applications are:

• ProgramMAIN (1.5MiB): the main program.
• ProgramMAIN2(600KiB): another important program.
• ProgramWP(8MiB): My main program (made with Qt).
• ProgramMINI(2.5Mib): My mini program (made with Qt).
• Program3(1.3MiB): My other program made with Qt (and the only one that just includes 1 lib)

All that programs (except the last one as I've already pointed) have the libraries linked statically but only mines are the ones that weight sooo much. I've see how much weights all the libs I link (the *.a file) and they are only 350KiB. So.. ofc, my bosses expect that my ProgramWP weights less than ProgramMAIN2 but nevertheless its 10 times bigger... :S

[jsulm]

You could try to use the strip tool to remove all not needed symbols from your binary:
strip YOUR_BINARY

[roseicollis]

@jsulm can you explain me how to use it? I don't know how does that tools work and didn't find it in google either. Thanks!

[kshegunov]

@roseicollis
I'll start top to bottom:

• unix:!macx: LIBS += -L$PWD/../../ConfigLib/Release/ -lLib1
  means to tell qmake to generate a makefile where your libraries are located in $PWD/../../ConfigLib/Release/ and you want to link Lib1 (filename libLib1.so). unix:!macx: tells qmake to do this for all *nix systems except macx.
• INCLUDEPATH += $PWD/../../Lib1 tells qmake to add a directory for includes that is $PWD/../../Lib1
• DEPENDPATH += $PWD/../../Libs/Release tells it add a directory for resolving dependencies
• unix:!macx: PRE_TARGETDEPS += $PWD/../../Libs/Release/Lib1.a This tells qmake that you actually want an archive file (.a) linked, not a shared object (dynamic library). Again, this is done for *nix systems that are not macx.

Here is a full reference of qmake's variables.

On the second part there are two main considerations:

1. Number of linked libraries (total amount of code to be included) and their size - all that you link statically will be copied in your executable, so this is a factor for size.
2. Code generated for your executable - Your own executable might be large, the static libraries aside. For example if you have many template instantiations this will swell your executable's size. Each of the templates is expanded and then compiled as a separate class, meaning QList<int> and QList<double> are two different classes (from the compiler's and/or linker's point of view) and code will be generated for each of them.

Additionally consider @jsulm's suggestion and strip the symbols you won't need. As far as I know, this could also be done by passing -s as an additional parameter to gcc (assuming you use that compiler). The relevant qmake variables are QMAKE_CXX_FLAGS for the compiler and QMAKE_LFLAGS for the linker respectively.

I hope this helps.
Kind regards.

[roseicollis]

@kshegunov
Wow, thank you for that explanation! About adding the -s to the gcc ....How can I add it? I mean.. i use to Ctr+R to compile and run my app (if release, if debug then F5). I've searched in the project properties but didn't found where can I add it.

[jsulm]

Try QMAKE_CFLAGS += -s in your *.PRO file

[kshegunov]

@roseicollis
You're welcome. I'd use QMAKE_CXX_FLAGS += -s in the .pro file, that's why I linked the two qmake variables in my previous post.
Also as @jsulm wrote QMAKE_CFLAGS might be used as well, but I'm not a 100% sure it'll be employed by qmake when compiling C++ source, so I suggest to use the C++ specific flags.

[roseicollis]

@kshegunov, @jsulm
I've added the QMAKE_CXX_FLAGS+= -s line. Notice that my line is diferent from your s(is th eonly one recognized by my version in Qt). Before adding it, I checked my exe (which was 8.1Mib) and after adding that line and compile it again... its the same... 8.1Mib (and also checked the properties to see if the last change hour was diferent, and was everything correct).

I'll copy part of my *.pro as it may be interesting some way maybe:

QT       += core gui
QT       += network
QT       += script
QT       += date
QT       += time
QT       += xml
QMAKE_CXXFLAGS += -std=c++11
QMAKE_CXX_FLAGS += -s

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET =MyProject
TEMPLATE = app


SOURCES + =...
HEDAERS += ...
FORMS+= ...

// *My statically linked libraries here* 

unix:!macx: LIBS += -lrt
unix:!macx: LIBS += -lexpat

Thanks!
P.d: (how do you mark in red a line here in the forum? I can't find the legend :P)

[jsulm]

Did you check whether -s was really passed to gcc (in the compiler output)?

[roseicollis]

@jsulm
Well... I get this:

15:58:52: Running steps for project MyProject...
15:58:52: Configuration unchanged, skipping qmake step.
15:58:52: Starting: "/usr/bin/make" 
make: Nothing to be done for `first'.
15:58:52: The process "/usr/bin/make" exited normally.
15:58:52: Elapsed time: 00:00.

so looking on the internet to see how can I avoid the "Configuration unchanged, skipping qmake step." found that I had to remove the makefile, which makes:

16:00:14: Running steps for project MyProject...
16:00:14: Starting: "/usr/bin/qmake-qt4" /home/suser/workspace/Path/Projects/MyProject/MyProject.pro -r -spec linux-g++
Project MESSAGE: Warning: unknown QT: date
Project MESSAGE: Warning: unknown QT: time
16:00:14: The process "/usr/bin/qmake-qt4" exited normally.
16:00:14: Starting: "/usr/bin/make" 
make: Nothing to be done for `first'.
16:00:14: The process "/usr/bin/make" exited normally.
16:00:14: Elapsed time: 00:00.

And if i clean and rebuild all the project and copy a part of all the message before it ends (if it ends rebuilding, all the messages are gone), I can see:

g++ -c -pipe -std=c++11 -s -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/lib/qt4/mkspecs/linux-g++ -I../MyProject-I/usr/include/QtCore -I/usr/include/QtNetwork -I/usr/include/QtGui -I/usr/include/QtXml -I/usr/include/QtScript -I/usr/include -I../../Utils -I../../Lib1-I../../Lib2-I../../Lib3-I../../Lib4-I. -I. -I../MyProject-I. -o wp2.o ../MyProject/wpmine.cpp

Where I can see the -s param clearly on the first line, fifth space. So I understand that the compiler efectively is using the -s param.

[kshegunov]

@roseicollis
The red text is inline code, you use it by putting the text between single backticks.

This is a very strange build command. You compile in debug but set the code to be optimized (twice no less) ... that aside I don't know what further to suggest, in principle it should be working, but I've not really used it so I don't know for sure.

[jsulm]

@roseicollis To avoid "Configuration unchanged" just rebuild your project