Date: Tue, 09 Sep 1997 21:22:15 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: file size
In-reply-to: <5v2qrt$4a5$1@grissom.powerup.com.au>
To: phreadd AT powerup DOT com DOT au (David Orme), djgpp AT delorie DOT com
Message-id: <199709090927.VAA09890@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization: Tait Electronics Limited
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On  9 Sep 97 at 6:37, David Orme wrote:

> Why are the programs I compile using BNU281 are larger than those
> compiled under BNU27?
> 
> 
> I do this (please tell me if I'm doing something redundant or
> wrong):
> 
> gcc -O3 -m486 source.c -o dest.exe
> strip dest.exe
> stubify dest.exe

The stubify is redundant because linking with gcc calls stubify for 
you.

Is the difference just shy of 2k (168 bytes I think)? If so, then it 
is because of the `strip dest.exe' command. bnu 2.8.1 (maybe 2.8) 
aligns coff sections to 4k, and as binutils groks the stub (hence 
strip working), the coff section get written out with at 4k 
boundaries. In other words, the file strip writes out has a slightly 
different format to what it read in, not counting the symbols.

***IMPORTANT NOTE*** DO NOT RUN DJP on a binutils 2.8 modified exe. 
djp doesn't handle the sections being moved about. (I know from 
experience, it bit me hard!!!).  This is not a bug in binutils, but 
an incompatability between djp and the new binutils. If you instead 
use:

gcc -O3 -m486 source.c -o dest.exe
strip dest
stubify dest
djp dest.exe

there will be no problems with the shifting sections, as they will be 
properly aligned in the file when strip sees them.

HTH
Bill
--
Leave others their otherness.