From: pavenis AT lanet DOT lv
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
        Laurynas Biveinis <lauras AT softhome DOT net>, djgpp-workers AT delorie DOT com
Date: Thu, 21 Jun 2001 13:52:38 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gcc-3.0
Message-ID: <3B31FC26.1141.5D4208@localhost>
References: <3B31DFC5 DOT 18980 DOT 6CD900 AT localhost>
In-reply-to: <Pine.SUN.3.91.1010621131654.9042D-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

On 21 Jun 2001, at 13:19, Eli Zaretskii wrote:

> 
> On Thu, 21 Jun 2001 pavenis AT lanet DOT lv wrote:
> 
> > #include <iostream>
> > 
> > int main(void)
> > {
> > 	std::cout << "Hello\n";
> > }
> > 
> > --------------------------------
> > after 'gpp -O2 hello.cc -o hello.exe' I'm getting the size of executable
> > (with gcc-3.0) size 1182238 bytes, after stripping it - 257536 bytes and
> > after compressing it with UPX 1.20 (option --best): 91068 bytes
> 
> What is the size of unstripped executable when libgcc.a is unstripped, as 
> opposed to stripped libgcc.a?

gcc-3.0, both libgcc.a and libstdxx.a stripped:
	original: 858371	   stripped: 255488	packed with UPX: 91008

gcc-2.95.3
	original: 383929	   stripped: 159232    packed with UPX: 72608 

> In other words, from this example it is not clear how much of this bloat 
> comes from libgcc.a and how much comes from libtsdc++.a and the code 
> emitted by the compiler.

Bloat comes mostly from libstdc++ (stripping libgcc.a gives about 60K in unstripped executable size)
> 
> (The general fact that GCC 3.0 generates monstrously large executable is 
> known quite well.  What can you expect from such a monstrously large 
> language, anyway?)

Some bloat may be also problem of binutils. Here is how looks begin of output of
'nm --extern-only --demangle some_my_app.exe':

         U .gnu.linkonce.d._ZNSt23__malloc_alloc_templateILi0EE26__malloc_alloc_oom_handlerE
         U .gnu.linkonce.d._ZNSt23__malloc_alloc_templateILi0EE26__malloc_alloc_oom_handlerE
         U .gnu.linkonce.d._ZNSt23__malloc_alloc_templateILi0EE26__malloc_alloc_oom_handlerE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE11_S_end_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE11_S_end_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE11_S_end_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_free_listE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_free_listE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_free_listE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_heap_sizeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_heap_sizeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE12_S_heap_sizeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE13_S_start_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE13_S_start_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE13_S_start_freeE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE22_S_node_allocator_lockE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE22_S_node_allocator_lockE
         U .gnu.linkonce.d._ZNSt24__default_alloc_templateILb1ELi0EE22_S_node_allocator_lockE
         U .gnu.linkonce.d._ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
         U .gnu.linkonce.d._ZTCSt19basic_istringstreamIcSt11char_traitsIcESaIcEE0_Si
         U .gnu.linkonce.d._ZTI13ExceptionBase
         U .gnu.linkonce.d._ZTIN15nmPolynomialFit13PolynomialFitE
         U .gnu.linkonce.d._ZTINSt6locale5facetE
         U .gnu.linkonce.d._ZTINSt6locale5facetE
         U .gnu.linkonce.d._ZTINSt6locale5facetE
        ........  there are more such lines  ...........

All these are not real unresolved references but results of binutils problems. The application
I got works.

So I think we don't have any DJGPP release of binutils ready for gcc-3.0. One can get
working executables though

Andris