Size of binaries.

Size of binaries.

[Jean-Pierre Radley]

Back in June, using whatever was the lastest experimental version of gcc
(I refresh it every week or so here), I compiled hylafax-4.1.2 on
OpenServer 5.0.6.

Today, using "gcc version 3.2 20020727 (experimental)", I compiled
hylafax-4.1.3.

The same options were used (-O -g).

The Hylafax code has relatively few changes between 4.1.2 and 4.1.3,
but the binaries are vastly larger. 

For example:

-r-xr-xr-x   1 root     sys       647220 Jun 10 15:43 /u/sbin/faxgetty.old
-rwxr-xr-x   1 root     sys      2226824 Aug  2 15:01 /u/sbin/faxgetty

The 'file' command reports:

/u/sbin/faxgetty:	ELF 32-bit LSB executable 80386, dynamically linked, stripped, debug
/u/sbin/faxgetty.old:	ELF 32-bit LSB executable 80386, dynamically linked, stripped, debug
	
What might be causing this increase in binary size of about 350% (I see
for all of Hylafax's binaries)?

I tried recompiling smail and tcsh, which were both last compiled almost
a year ago.  The smail binary came out trivially different, while the
tcsh binary was in fact a bit smaller.

The Hylafax code is mostly in C++, and I have really no other C++ source
code to play with just now.  I did see the following warning for just
about every *.c++ file:

        /usr/local/include/c++/3.2/backward/backward_warning.h:32:2:
        warning: #warning This file includes at least one deprecated
        or antiquated header. Please consider using one of the 32
        headers found in section 17.4.1.2 of the C++ standard. Examples
        include substituting the <X> header for the <X.h> header for
        C++ includes, or <sstream> instead of the deprecated header
        <strstream.h>. To disable this warning use -Wno-deprecated.

-- 
JP

Re: Size of binaries.

[Joe Buck]

[ larger C++ executables when -g is used ]

> /u/sbin/faxgetty:	ELF 32-bit LSB executable 80386, dynamically linked, stripped, debug
> /u/sbin/faxgetty.old:	ELF 32-bit LSB executable 80386, dynamically linked, stripped, debug
> 	
> What might be causing this increase in binary size of about 350% (I see
> for all of Hylafax's binaries)?

The main source of the size increase is almost certainly the size of the
debug info for the classes from the standard library.  libstc++ v3 is
substantially larger, because it's a complete (ISO C++) implementation,
while the old library was missing many features, and used plain classes
in many places where templates are now required.

I don't know how much redundancy may exist in the debug info, I suspect
that there are opportunies for reducing the file size. But the priority
up to this point has been on getting a complete and correct C++
implementation, not on size optimization.

> I tried recompiling smail and tcsh, which were both last compiled almost
> a year ago.  The smail binary came out trivially different, while the
> tcsh binary was in fact a bit smaller.

They are C.

Re: Size of binaries.

[Jean-Pierre Radley]

Joe Buck propounded (on Fri, Aug 02, 2002 at 02:43:08PM -0700):
| [ larger C++ executables when -g is used ]
| 
| > What might be causing this increase in binary size of about 350% (I see
| > for all of Hylafax's binaries)?
| 
| The main source of the size increase is almost certainly the size of the
| debug info for the classes from the standard library.  libstc++ v3 is
| substantially larger, because it's a complete (ISO C++) implementation,
| while the old library was missing many features, and used plain classes
| in many places where templates are now required.

¡Muchísimas gracias, ruiseñor!

Once having hacked HylaFax's configure script to NOT use -g as a gcc
option, its binaries came back down to more or less the same number of
bytes as those of the prior HylaFax release.

-- 
JP