Qt-interest Archive, August 2007
Small Static Executables
Pages: Prev | 1 | 2 | Next
Message 16 in thread
It may be a QTopia only app... Try downloading the open source qtopia source, and building it using QT
________________________________
From: Benjamin Pollack [mailto:benjamin.pollack@xxxxxxxxx]
Sent: Mon 8/20/2007 1:09 PM
To: Scott Aron Bloom
Cc: Qt Interest List
Subject: Re: Small Static Executables
On 8/20/07, Scott Aron Bloom <scott@xxxxxxxxxxxx> wrote:
Take a look at the QTSRC/tools/qconfig application that is shipped with
QT.
In Qt 4.3.0 Open-Source Edition, I don't seem to have a qconfig application there. Does it only come with the commercial version?
--Benjamin
--
[ signature omitted ]
Message 17 in thread
At the first look the MS choice appears much better, above all because today
we have very very fast hw platform so that a bigger linking time shouldn't be
appreciated.
Is it really so? GNU linker is really so worse than MS one?
Regards
Alle 19:18, lunedì 20 agosto 2007, Till Oliver Knoll ha scritto:
> Thomas Richards schrieb:
> > Hi,
> >
> >> The GNU linker doesn't pull in the entire library, it is smarter than
> >> that. It includes only the files that are used (as opposed to only
> >> the *functions* that are used, like e.g. Microsoft's compiler).
> >
> > Just curious... Although you don't say so explicitly, it seems like
> > you're implying that this is better then the MS approach.
>
> No, only including the needed functions (as is obviously done by the MS
> compiler) is off course better; including the whole *.cpp file (as
> obviously done by the gcc), that is the whole compilation unit,
> naturally also includes all the non-needed functions which adds
> unnecessary size to the executable.
>
> That's how I interpreted Gordon's posting.
>
> Cheers, Oliver
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 18 in thread
Fabio Giovagnini <fabio.giovagnini@xxxxxxxxxxxxxxx> wrote on 08/20/2007
11:56:18 AM:
# At the first look the MS choice appears much better, above all because
today
# we have very very fast hw platform so that a bigger linking time
shouldn't be
# appreciated.
# Is it really so? GNU linker is really so worse than MS one?
How about "missing that feature", for the moment. I'm not qualified to
say which one's "better" overall; at the bare minimum, they can both
do things the other can't. (If nothing else, MS's runs on four platforms
and GNU's on, what... forty?)
--
[ signature omitted ]
Message 19 in thread
"Thomas Richards" <thomas.richards@xxxxxxxxx> wrote on 08/20/2007 10:49:19
AM:
# Just curious... Although you don't say so explicitly, it seems like
# you're implying that this is better then the MS approach.
#
# I have no idea which is better (in terms of final executable size), but
# surely pulling in individual functions, rather than pages, would lead to
# a smaller executable? (if perhaps at the cost of a longer linking time).
Er, no - I didn't mean to imply that. MS has the right of it there;
it's another one of those things that the binutils folks acknowledge
as a weakness. I can't find the reference at the moment.
FWIW, the combination of -ffunction-sections, -fdata-sections, and
-Wl,--gc-sections should accomplish approximately the same thing (if
it works on your platform).
--
[ signature omitted ]
Message 20 in thread
On Monday 20 August 2007 10:44:37 Gordon.Schumacher@xxxxxxxxxxx wrote:
> "Peter Prade" <prade@xxxxxxxxxxx> wrote on 08/20/2007 10:14:09 AM:
>
> # Well, static Qt apps (that use gui) tend to be rather large. this is
> # normal.
> # Qt 4 is now divided into parts that you can leave out (like xml, sql,
> # etc.) but all gui elements still remain in one lib. (you can't specify
> # that you only need a label, you get all the gui elements and there is no
> # easy way around this)
> #
> # If you really need to strip this down, you'll need to make your own qt
> # libs that remove code that you don't need. I guess this would be a
> # difficult task.
>
> The GNU linker doesn't pull in the entire library, it is smarter than
> that. It includes only the files that are used (as opposed to only
> the *functions* that are used, like e.g. Microsoft's compiler).
>
> That said, I'd make sure that, as already suggested, you turn off
> every single feature you don't need in the Qt build, as it will
> reduce internal dependencies within Qt (and thus reduce the files
> that will get included).
>
> Lastly, there are some gcc and ld switches that may help:
> -Os (instead of -O2)
> -fmerge-all-constants
> -fno-default-inline
> -fno-inline
> possibly -ffunction-sections, -fdata-sections, and -Wl,--gc-sections
>
> You will have to modify the qmakespec file for your platform in
> order to do this. Do this *before* building Qt, so that Qt
> itself will get built with the changed settings.
>
> See http://gcc.gnu.org/onlinedocs/gcc-4.2.1
> /gcc/Optimize-Options.html#Optimize-Options
> for reference on these options. (The --gc-sections option is a
> linker option - see 'info ld' instead.)
You'll also want to strip the resulting executable if you have not already
been doing this. strip(1).
--
[ signature omitted ]
Message 21 in thread
Chris Thompson <cthompson@xxxxxxxxxxxxxxx> wrote on 08/20/2007 10:53:02 AM:
# You'll also want to strip the resulting executable if you have not
already
# been doing this. strip(1).
I *think* that simply compiling your release-mode application without -g
should accomplish the same thing, with the default parameters to strip.
(It doesn't under DJGPP/DOS, but that's considered a bug, and I doubt that
is what you are using.)
--
[ signature omitted ]
Message 22 in thread
On Mon, Aug 20, 2007 at 11:43:20AM -0600, Gordon.Schumacher@xxxxxxxxxxx wrote:
> Chris Thompson <cthompson@xxxxxxxxxxxxxxx> wrote on 08/20/2007 10:53:02 AM:
>
> # You'll also want to strip the resulting executable if you have not
> already
> # been doing this. strip(1).
>
> I *think* that simply compiling your release-mode application without -g
> should accomplish the same thing, with the default parameters to strip.
> (It doesn't under DJGPP/DOS, but that's considered a bug, and I doubt that
> is what you are using.)
>
That is not my experience. Strip does not only remove debug symbols, but
also some other unneeded stuff:
#include <stdio.h>
int main (void)
{
printf("Hello World!\n");
return 0;
}
compiled with and without -g and then stripped produces the attached
executable sizes.
regards,
Andre
-rwxr-xr-x 1 ahaupt ahaupt 8233 2007-08-21 10:32 test_debug
-rwxr-xr-x 1 ahaupt ahaupt 8233 2007-08-21 10:32 test_debug
-rwxr-xr-x 1 ahaupt ahaupt 3480 2007-08-21 10:32 test_debug_stripped
-rwxr-xr-x 1 ahaupt ahaupt 7485 2007-08-21 10:32 test_release
-rwxr-xr-x 1 ahaupt ahaupt 3480 2007-08-21 10:32 test_release_stripped
Message 23 in thread
> The GNU linker doesn't pull in the entire library, it is smarter than
> that. It includes only the files that are used (as opposed to only
> the *functions* that are used, like e.g. Microsoft's compiler).
while this is true, i think that the meta-object information that Qt
adds will in turn pull in all slots of all QObject derived objects and
those will probably pull in most of the code.
The linker can't know which slots could possibly become connected!
Cheers,
Peter
(so if you want to reduce the size, you'll have to remove the classes
you don't need from your custom build)
--
[ signature omitted ]
Message 24 in thread
On 8/20/07, Gordon.Schumacher@xxxxxxxxxxx <Gordon.Schumacher@xxxxxxxxxxx>
wrote:
>
> That said, I'd make sure that, as already suggested, you turn off
> every single feature you don't need in the Qt build, as it will
> reduce internal dependencies within Qt (and thus reduce the files
> that will get included).
>
> Lastly, there are some gcc and ld switches that may help:
> -Os (instead of -O2)
> -fmerge-all-constants
> -fno-default-inline
> -fno-inline
> possibly -ffunction-sections, -fdata-sections, and -Wl,--gc-sections
>
Thanks for everyone's advice. I followed Gordon's suggestions above, adding
those linker options to the qmakespec, and rebuilt Qt. The configure command
I used was "-static -release -no-qt3support -no-style-cde -no-style-motif
-no-style-cleanlooks -no-style-plastique". I then rebuilt
hello.exestatically against the release libraries. The new executable
is
5.4 MB--a huge improvement from the 7.5 MB of the original, but not quite
good enough. Using UBX, I can cut that down to about 2.6 MB--still more than
twice as large as my maximum size.
Ah well. I'm sure I'll have use for Qt in something else--just not this.
--Benjamin
Message 25 in thread
"Benjamin Pollack" <benjamin.pollack@xxxxxxxxx> wrote on 08/20/2007
02:06:16 PM:
# Thanks for everyone's advice. I followed Gordon's suggestions above,
# adding those linker options to the qmakespec, and rebuilt Qt. The
# configure command I used was "-static -release -no-qt3support -no-
# style-cde -no-style-motif -no-style-cleanlooks -no-style-plastique".
# I then rebuilt hello.exe statically against the release libraries.
# The new executable is 5.4 MB--a huge improvement from the 7.5 MB of
# the original, but not quite good enough. Using UBX, I can cut that
# down to about 2.6 MB--still more than twice as large as my maximum size.
Out of curiosity... is that Win32 (MinGW) or Linux?
I ask because I don't know what your specifications are for Windows,
but if you can you might also try building the same project with
Studio and see if it can do better. I've little experience with
MinGW but I'd be unsurprised to learn that Microsoft's own compiler
could do better size optimization.
http://kjellkod.blogspot.com/2007/02/qt4-on-free-ide-visual-studio-express.html
Much the same should work for a commercial VS install; the critical
part is the "advanced compiler tools" patch they link to here:
http://sourceforge.net/project/showfiles.php?group_id=49109
Of course, if this is testing for a commercial project, you could
also just download the trial license and go from there.
--
[ signature omitted ]
Message 26 in thread
On 8/20/07, Gordon.Schumacher@xxxxxxxxxxx <Gordon.Schumacher@xxxxxxxxxxx>
wrote:
>
> Out of curiosity... is that Win32 (MinGW) or Linux?
MinGW in this case, though I've also been testing these suggestions on OS
X's GCC (see below).
I ask because I don't know what your specifications are for Windows,
> but if you can you might also try building the same project with
> Studio and see if it can do better. I've little experience with
> MinGW but I'd be unsurprised to learn that Microsoft's own compiler
> could do better size optimization.
In my opinion, despite its many other failings, Microsoft produces a superb
compiler chain, but the whole reason we're looking at Qt is to try to avoid
having to maintain separate Mac, Windows, and Linux versions. Having a 20 kB
Windows build under Visual Studio accomplishes nothing if the OS X build
from GCC still weighs 4 MB. So, sadly, it's GCC or bust at this point.
--Benjamin
Message 27 in thread
Are we talking about the 'debug' or 'release' versions of your program?
The former is much larger than the latter.
DS
----- Original Message ----
From: Benjamin Pollack <benjamin.pollack@xxxxxxxxx>
To: qt-interest@xxxxxxxxxxxxx
Sent: Monday, August 20, 2007 9:04:38 AM
Subject: Small Static Executables
Hey all,
I'm learning Qt with the hope of using it for an upcoming product where I work. One problem is that, for the app I want to use it for, size matters a lot. I'd really need a statically linked Qt app to be no more than a megabyte at the outside. Instead, even with dead code stripping and a few other options, the smallest I can get a "Hello, world!" app that does nothing other than display a QLabel is about
7.5 MB MB, both on Windows and on Mac. Using a compressor thunk on top of that only trims it to about 3-4 MB. Is this normal, or am I missing something obvious? Intuitively, the application should be far smaller, but I can see where dependencies within Qt or deficiencies within GCC's linker may make the actual minimum higher than it needs to be.
Thanks much for any help you can provide.
--Benjamin
Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca
