DJGPP's .exe's are TOO large
laf...@utdallas.edu
The program :
main() {
}
compiles to something like 30 or 40k! What gives. If you then use just
a couple library functions your code size goes up to around 50 or 60k.
Am I setting the program up wrong or what? Do the programs really need
that huge "library chunk" of data to run? I can put up with the slow
compile time, but I make up a lot of little apps, and it just seems that
they're taking up a heck of a lot more disk space then they need be.
Just wondering... Please mail replies to laf...@utdallas.edu
Rei
John M. Aldrich
What you are seeing is the startup code for DJGPP v2 which includes support
for, among other things, command-line globbing, environment loading, and FPU
emulation, not to mention the DPMI loader. Also, if you compile without -s,
your program includes symbol information used in debugging. Section 8.15
of the FAQ (available as v2/faq201b.zip from any SimTel mirror) gives a
detailed description of this and also gives instructions on how to reduce
the size of your executables (to as little as 18K for a "Hello World").
Please also note that, as has been discussed before, "Hello World" is NOT
a realistic test case to determine the size of a program. The startup
code is a fixed size, and while it does bloat small programs, it is a
trivial part of large ones. In general, DJGPP code compiles smaller and
faster than almost any other 32-bit compiler.
FYI, here's a brief summary of the instructions in the FAQ. To reduce the
final size of a DJGPP compiled program, you can do any or all of the
following:
1) Compile your code with -s to strip debugging information. Alternatively,
run 'strip' on your compiled object code, then relink.
2) #include <crt0.h> in your program and define empty versions of any or all
of the functions __crt0_glob_function, __crt0_setup_arguments, and
__crt0_load_environment_file. Note that this will DISABLE the corresponding
functionality from your program.
3) Compress your executables with DJP, the DJGPP executable packer. Pointers
to it are in the FAQ.
HTH!
--
John M. Aldrich, aka Fighteer I <figh...@cs.com>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s+:- a-->? c++>$ U@>++$ p>+ L>++ E>+ W+>++ N++ o+ K? w(---) O-
M-- V? PS+ PE Y+ PGP- t+(-) 5- X- R+ tv+() b+++ DI++ D++ G e(*)>++++
h!() !r !y+()
------END GEEK CODE BLOCK------
Vladislav Panferov
laf...@utdallas.edu wrote:
>
> The program :
> main() {
>
> }
> compiles to something like 30 or 40k! What gives. If you then use just
> Rei
Please read the Section 8.15 of the DJGPP FAQ v2.01 which should
be available at the same place you got DJGPP (file v2/faq201b.zip).
A *full* answer is there definitely.
Good luck,
Vladislav
Mark Habersack
On 11 Aug 1996 laf...@utdallas.edu wrote:
> The program :
>main() {
>
>}
>compiles to something like 30 or 40k! What gives. If you then use just
What gives? The djgpp startup code has a lot of to do with setting up your
app to run in prot mode. Formerly the stuff was in an external program but now
it is incorporated in to your app - and that's good.
>a couple library functions your code size goes up to around 50 or 60k.
Ever tried to use BC4.X+ compilers? Noticed how big they are - and what takes
place there is just an exception-handling code. Add to that the 150K rtm.exe
and you have 200K just to say "Hello world". Is 40K so much in that light?
>Am I setting the program up wrong or what? Do the programs really need
>that huge "library chunk" of data to run? I can put up with the slow
>compile time, but I make up a lot of little apps, and it just seems that
It's as fas as WATCOM.
>they're taking up a heck of a lot more disk space then they need be.
But if you make the app more and more complex, it doesn't grow so much - have
you noticed that?
>Just wondering... Please mail replies to laf...@utdallas.edu
>
If you're making little apps then better stick to real mode and TC++ or
something similar. If you really want to create small 32-bit apps and the
executables are too big for you - get djp, it will save about 60% of the space
occupied by an unpacked executable.
>Rei
>
>
/************************************************************/
/** Maybe it was infatuation or the thrill of a chase? **/
/** Maybe you were always beyond my reach and my heart **/
/** was playing safe? ***********/
/** But was that love in your eyes I saw, **/
/** or the reflection of mine? **/
/** I'll never really know for sure, **/
/** You never really gave me time! **/
/** Won't you give me that time? **/
/** "Cindirella Search" **/
/********************************/
Visit my homepage: http://ananke.amu.edu.pl/~grendel
Steve Piner
In article <Pine.NEB.3.95.960812...@ananke.amu.edu.pl>,
Mark Habersack <gre...@ananke.amu.edu.pl> wrote:
: On 11 Aug 1996 laf...@utdallas.edu wrote:
:
: > The program :
: >main() {
: >
: >}
: >compiles to something like 30 or 40k! What gives.
: If you're making little apps then better stick to real mode and TC++ or
: something similar. If you really want to create small 32-bit apps and the
: executables are too big for you - get djp, it will save about 60% of the
: space occupied by an unpacked executable.
Another little trick is to strip your Coff files. Gcc adds some
rudimentary debug info even when compiling without the '-g' option.
If you compile to Coff - 'gcc -o foo ...' - rather than exe -
'gcc -o foo.exe ...' - then you can strip the resulting binary and use
stubify to turn it into a much smaller exe.
Steve
--
____ ____
/ __//___ \ Steve Piner - spi...@comp.vuw.ac.nz
\__ \ | _/-----------------------------------------------------
/___/ |_| (yes, I know it's a BUAF, but it's *my* BUAF) :-)
Alexander Lehmann
Steve Piner <spi...@comp.vuw.ac.nz> wrote:
: In article <Pine.NEB.3.95.960812...@ananke.amu.edu.pl>,
: Mark Habersack <gre...@ananke.amu.edu.pl> wrote:
: : On 11 Aug 1996 laf...@utdallas.edu wrote:
: :
: : > The program :
: : >main() {
: : >
: : >}
: : >compiles to something like 30 or 40k! What gives.
: ...[Stuff about startup code snipped]
: : If you're making little apps then better stick to real mode and TC++ or
: : something similar. If you really want to create small 32-bit apps and the
: : executables are too big for you - get djp, it will save about 60% of the
: : space occupied by an unpacked executable.
: Another little trick is to strip your Coff files. Gcc adds some
: rudimentary debug info even when compiling without the '-g' option.
: If you compile to Coff - 'gcc -o foo ...' - rather than exe -
: 'gcc -o foo.exe ...' - then you can strip the resulting binary and use
: stubify to turn it into a much smaller exe.
Or you can strip the COFF binary and recreate a new .exe with coff2exe
(or if you have only the .exe first exe2coff, strip and then
coff2exe). This works even with executables that are acidentally
distributed unstripped (jpeg386 did that at one point, I think).
bye, Alexander
--
Alexander Lehmann, | "On the Internet,
al...@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows
leh...@mathematik.th-darmstadt.de (plain) | you're a dog."
<URL:http://www.mathematik.th-darmstadt.de/~lehmann/>
Elliott Oti
Alexander Lehmann wrote:
>
> : Another little trick is to strip your Coff files. Gcc adds some
> : rudimentary debug info even when compiling without the '-g' option.
> : If you compile to Coff - 'gcc -o foo ...' - rather than exe -
> : 'gcc -o foo.exe ...' - then you can strip the resulting binary and use
> : stubify to turn it into a much smaller exe.
>
> Or you can strip the COFF binary and recreate a new .exe with coff2exe
> (or if you have only the .exe first exe2coff, strip and then
> coff2exe). This works even with executables that are acidentally
> distributed unstripped (jpeg386 did that at one point, I think).
>
> bye, Alexander
>
Some standard functions are much larger than others:
printf() smacks 30k extra. Use puts() instead if possible.
Compiling with -ffast-math , -fomit-frame-pointer reduces
size too. (Of course, these switches carry their own attendant
dangers).
But really, the size problem isn't too bad. There's a bare minimum
of around 50k for the extender code, but the PMODE 2.5 assembly
extender by Tran (Thomas Pytel), the best freeware assembly extender
around, also adds 30k extra to the .exe file. So much for the
compactness of assembler.
I think a lot of dead weight after that comes from certain standard
C functions like printf(), and the error-handling associated
with them. Trial and error should show which ones are the worst.
-Elliott
Malcolm Taylor
Elliott Oti <e....@stud.warande.ruu.nl> wrote:
>Alexander Lehmann wrote:
>> : Another little trick is to strip your Coff files. Gcc adds some
The easiest way to do this is:
gcc -s -o name.exe
Which will strip it before it gets stubbed.
>But really, the size problem isn't too bad. There's a bare minimum
>of around 50k for the extender code,
The overhead code is only around 20K if I remember right if you
remember to define a few empty functions (see the FAQ section
referenced earlier in this thread).
Also never go past DJP. This has extremely good compression ratios for
an exe packer, and can get your exe quite small.
>but the PMODE 2.5 assembly
>extender by Tran (Thomas Pytel), the best freeware assembly extender
>around, also adds 30k extra to the .exe file. So much for the
>compactness of assembler.
Actually PMODE adds 15K to your exe file. I have actually myself
packed this executable as well gaining another 5K. Note though that
packing the PMODE stub means the program cannot be spawned by other v2
apps anymore (I don't know why though :).
>I think a lot of dead weight after that comes from certain standard
>C functions like printf(), and the error-handling associated
>with them. Trial and error should show which ones are the worst.
If you're still looking for space after that you can always get the
library sources and modify the functions that you use to remove some
of the 'unecessary stuff' like error handling :-). I used mkdir in my
prog and had 8K extra linked in just for the error handling and access
functions it used. For my prog I didn't need this, so I lost the 8K
again just by recompiling the function.
As a testamony I have written a fully functional archiver that is only
50K long. This is shorter than most of the others I have seen, and
they don't even use protected-mode!
Malcolm
Mark Habersack
On Thu, 15 Aug 1996, Malcolm Taylor wrote:
>>But really, the size problem isn't too bad. There's a bare minimum
>>of around 50k for the extender code,
>
>The overhead code is only around 20K if I remember right if you
>remember to define a few empty functions (see the FAQ section
>referenced earlier in this thread).
I think Elliot was talking about the stuff that stays in memory when server is
run.
>Also never go past DJP. This has extremely good compression ratios for
>an exe packer, and can get your exe quite small.
>
>>but the PMODE 2.5 assembly
>>extender by Tran (Thomas Pytel), the best freeware assembly extender
>>around, also adds 30k extra to the .exe file. So much for the
>>compactness of assembler.
>
>Actually PMODE adds 15K to your exe file. I have actually myself
Again, memory.
>>I think a lot of dead weight after that comes from certain standard
>>C functions like printf(), and the error-handling associated
>>with them. Trial and error should show which ones are the worst.
>
>As a testamony I have written a fully functional archiver that is only
>50K long. This is shorter than most of the others I have seen, and
>they don't even use protected-mode!
Is it available anywhere?
Mark
Mark Habersack
On Tue, 13 Aug 1996, Elliott Oti wrote:
>Alexander Lehmann wrote:
>>
>> : Another little trick is to strip your Coff files. Gcc adds some
>> : rudimentary debug info even when compiling without the '-g' option.
>> : If you compile to Coff - 'gcc -o foo ...' - rather than exe -
>> : 'gcc -o foo.exe ...' - then you can strip the resulting binary and use
>> : stubify to turn it into a much smaller exe.
>>
>> Or you can strip the COFF binary and recreate a new .exe with coff2exe
>> (or if you have only the .exe first exe2coff, strip and then
>> coff2exe). This works even with executables that are acidentally
>> distributed unstripped (jpeg386 did that at one point, I think).
>>
>> bye, Alexander
>>
>
>Some standard functions are much larger than others:
>printf() smacks 30k extra. Use puts() instead if possible.
>Compiling with -ffast-math , -fomit-frame-pointer reduces
^^^^^speaking of this one. I read that this
switch causes WinXX to break down??? Well, I use it all the time and so far no
failures!! So have anyone of you had any problems of this nature with the
switch? And if so, in what environment (I checked Win3.11, Win95 & WinNT -
everything's OK)
>size too. (Of course, these switches carry their own attendant
>dangers).
>But really, the size problem isn't too bad. There's a bare minimum
>of around 50k for the extender code, but the PMODE 2.5 assembly
You mean the stuff that remains resident in memory, right?
>extender by Tran (Thomas Pytel), the best freeware assembly extender
>around, also adds 30k extra to the .exe file. So much for the
>compactness of assembler.
>I think a lot of dead weight after that comes from certain standard
>C functions like printf(), and the error-handling associated
>with them. Trial and error should show which ones are the worst.
Checking up the sizes of .o modules in libc.a should do here...
But, hey! Hard disks are getting bigger and bigger today, so why so much noise
about the space? "Much ado for nothing".
Elliott Oti
Mark Habersack wrote:
>
> On Tue, 13 Aug 1996, Elliott Oti wrote:
>
> >Compiling with -ffast-math , -fomit-frame-pointer reduces
> ^^^^^speaking of this one. I read that this
> switch causes WinXX to break down??? Well, I use it all the time and so far no
> failures!! So have anyone of you had any problems of this nature with the
> switch? And if so, in what environment (I checked Win3.11, Win95 & WinNT -
> everything's OK)
>
info says that using -fomit-frame-pointer prevents debugging on i386 machines
(never tried it meself), but I find Mark's question an interesting one.
I try to make my programs as Win-friendly as possible, and they crash
fairly often ( sound routines especially playing mods are the worst
culprits), but the switch has little to do with it. I now use it all
the time, as the extra register makes ALL the difference. Still -- where there's
smoke, there's fire . Only, where's the fire? Any of you guys seen fire?
Any ideas, Eli?
Charles Sandmann
> info says that using -fomit-frame-pointer ...
This switch only causes problems under V1.x and DPMI. The stack overflow
protection selector was removed in V2.0, but now you don't notice when you
overrun the stack (with V1.x you would get a stack fault).
Serge Pachkovsky
Elliott Oti (e....@stud.warande.ruu.nl) wrote:
: info says that using -fomit-frame-pointer prevents debugging on i386 machines
: (never tried it meself), but I find Mark's question an interesting one.
: I try to make my programs as Win-friendly as possible, and they crash
: fairly often ( sound routines especially playing mods are the worst
: culprits), but the switch has little to do with it. I now use it all
: the time, as the extra register makes ALL the difference. Still -- where there's
: smoke, there's fire . Only, where's the fire? Any of you guys seen fire?
Oh, sure. Quite a lot of, actually ;-)
The problem with -fomit-frame-pointer under DPMI is that it frees up an
extra register (bp) for general use. x86 use SS: as the default selector
when bp is used as an address base register, and if SS: happen to be
unequal to DS:, and your data is in DS:, you lose with segmentation fault.
So, as long all your pointers are to stack-based objects (or you are not
using pointers at all) you are free to compile with -fomit-frame-pointer.
It should be fairly easy to fix in gcc (just emit an extra ds: segment
override if using bp as a base register and -fomit-frame-pointer is in
effect). For all I know, it might have already been fixed (my experience
with gcc on x86 ends some time around 2.6.3, and that's history by now).
Regards,
/Serge.P
--
Russian guy from the Zurich university...
Eli Zaretskii
On Tue, 20 Aug 1996, Elliott Oti wrote:
> Mark Habersack wrote:
> >
> > On Tue, 13 Aug 1996, Elliott Oti wrote:
> >
> > >Compiling with -ffast-math , -fomit-frame-pointer reduces
> > ^^^^^speaking of this one. I read that this
> info says that using -fomit-frame-pointer prevents debugging on i386 machines
> (never tried it meself), but I find Mark's question an interesting one.
-fomit-frame-pointer shouldn't do any harm in DJGPP v2. In v1.x, it
could crash your program under DPMI, but v2 doesn't have such problems
anymore. Using that switch does prevent debugging, but makes programs
faster.
Eli Zaretskii
On 21 Aug 1996, Serge Pachkovsky wrote:
> Oh, sure. Quite a lot of, actually ;-)
> The problem with -fomit-frame-pointer under DPMI is that it frees up an
> extra register (bp) for general use. x86 use SS: as the default selector
> when bp is used as an address base register, and if SS: happen to be
> unequal to DS:, and your data is in DS:, you lose with segmentation fault.
This problem doesn't exist in DJGPP v2. The above describes what
happened when you use -fomit-frame-pointer in DJGPP v1.x.