Ouch! Install size went from 18M to 900M.

Ouch! Install size went from 18M to 900M.

[John Morrison]

Hi all.

I'm upgrading the cross compiler, under Solaris 5.8 and Linux, from gnu
2.95.2 & Binutils 1.11 TO gnu 4.2.0 & Binutils 1.17.
(--enable-languages=c,c++)

I can not believe that the compiler and binutils increased that much
between 2.95.2 and 4.2.0.  What can I specify to cut this down?  There
must have been something that opted in that I can turn off.

No one here remembers what options were specified last time.  

Any help would be appreciated.



gnu 2.95.2 & Binutils 1.11

du -sk *
68480   bin
156     include
1660    info
24884   lib
280     man
18892   powerpc-eabi
4       share



gnu 4.2.0 & Binutils 1.17

du -sk *
66400   bin
4       include
1932    info
6156    lib
104484  libexec
1656    man
744576  powerpc-eabi
9524    share	



Even the linux version doubled in size:

 $du -sk gcc.ppc      
353636  gcc.ppc

 $du -sk gcc.ppc-4.2.0
696140  gcc.ppc-4.2.0



Thanks

John Morrison
Printronix, Inc.

Re: Ouch! Install size went from 18M to 900M.

[Brian Dessent]

John Morrison wrote:

> I can not believe that the compiler and binutils increased that much
> between 2.95.2 and 4.2.0.  What can I specify to cut this down?  There
> must have been something that opted in that I can turn off.

I would guess mutlilibs and debug info contribute to that.  You can
print the list of multilibs configured for your target with
-print-multi-lib, and if it's too many or you don't need multilib
capability you can --disable-multilib when configuring.  Some targets
build a great number of multilibs.

To strip debug info there are a number of techniques, e.g. 'make
LDFLAGS="-s"'.

But really, you have the before and after files, we don't.  So it would
seem you are the only one that can truly answer this question.  gcc is a
complex program with many optional supporting libs/features, and
supports so many various targets that it's hard to just pick and ancient
version built with unknown options and recent version and tell what's
different given only disk space usage.

Brian

RE: Ouch! Install size went from 18M to 900M.

[John Morrison]

Thanks Brian.

Looks like Multilib was the major difference.  The 2.95.2 build
responded with ".;" while the 4.2.0 build responded with 8 libraries.

I'm about to try a build with --disable-multilib and see what happens.

I just needed some hints on where to look. 

That helped.  

Thanks
John Morrison
Printronix, Inc 

-----Original Message-----
From: Brian Dessent [mailto:brian@dessent.net] 
Sent: Tuesday, April 08, 2008 3:05 PM
To: John Morrison
Cc: gcc-help@gcc.gnu.org
Subject: Re: Ouch! Install size went from 18M to 900M.

John Morrison wrote:

> I can not believe that the compiler and binutils increased that much 
> between 2.95.2 and 4.2.0.  What can I specify to cut this down?  There

> must have been something that opted in that I can turn off.

I would guess mutlilibs and debug info contribute to that.  You can
print the list of multilibs configured for your target with
-print-multi-lib, and if it's too many or you don't need multilib
capability you can --disable-multilib when configuring.  Some targets
build a great number of multilibs.

To strip debug info there are a number of techniques, e.g. 'make
LDFLAGS="-s"'.

But really, you have the before and after files, we don't.  So it would
seem you are the only one that can truly answer this question.  gcc is a
complex program with many optional supporting libs/features, and
supports so many various targets that it's hard to just pick and ancient
version built with unknown options and recent version and tell what's
different given only disk space usage.

Brian

Re: Ouch! Install size went from 18M to 900M.

[Brian Dessent]

John Morrison wrote:

> Looks like Multilib was the major difference.  The 2.95.2 build
> responded with ".;" while the 4.2.0 build responded with 8 libraries.
> 
> I'm about to try a build with --disable-multilib and see what happens.
> 
> I just needed some hints on where to look.

If you don't build multilibs then you need to ensure that the default
configuration matches your use case.  Multilibbing is a convenience that
builds a number of versions of the libraries so that the correct one can
be chosen at link time based on the options used.  So for example if you
compile and link with -msoft-float then it will know to link your code
with the libgcc or libstdc++ that was also built with -msoft-float.

But if you disable multilib support then those support libraries will
only be built once, and so the options used during the gcc build have to
be compatible with the options you eventually plan to use with the
toolchain.  You can set those defaults using --with-float=hard|soft,
--with-cpu=arch, or --with-tune=arch.

Alternatively, according to the docs some targets give you fine grained
control over disabling individual multilib variants, so that would also
be something to consider instead of throwing out multilibs entirely.  It
looks like for powerpc you can --disable-$foo for $foo in aix64,
pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, sysv,
aix.

Brian