gcc code bloat
Kai Ruottu
kai.ruottu@luukku.com
Thu Dec 7 03:30:00 GMT 2000
Jim Fischer wrote:
>
> ----- Original Message -----
> From: <andy@softbookpress.com>
> To: <crossgcc@sources.redhat.com>
> Sent: Tuesday, December 05, 2000 2:20 PM
> Subject: gcc code bloat
>
> > I have an armv4l box running Linux with gcc 2.95.1
> > I see a rather significant size increase when compiling my C++ code with
> > gcc ( g++ to be exact) even with -02 optimization level vs MetroWerks C++
> > on the Mac
> > Is there anything I can do about it ?
> > The code uses templates, namespaces and exceptions.
>
> Comment 2) I suspect that the executable images you're producing with
> MetroWerks C++ are smaller because they are linking with the C++ libraries
> dynamically (i.e., at runtime). IOW, the C/C++ runtime libs are actually
> dynamic link libraries (DLLs), and your program is loading these DLLs into
> memory -- and linking with them -- at runtime. To verify this, rebuild your
> executable images with MetroWerks C++ using only static linking and then
> recheck the sizes of the executables.
The 'libstdc++' should have been built as an shared library (.so) for the
'armv4l-linux'... If it wasn't, this is the problem. The building happens
using the '--enable-shared' option while configuring the GCC sources.
For instance the following example program from the Osborne book "Borland C++,
The Complete Reference" (Chapter 24, example 3):
----------------------------- clip ------------------------------------------
#include <iostream.h>
class three_d {
int x, y, z; // 3-d coordinates
public:
three_d(int a, int b, int c) {x=a; y=b; z=c;}
friend ostream &operator<<(ostream &stream, three_d obj);
friend istream &operator>>(istream &stream, three_d &obj);
} ;
// Display X, Y, Z coordinates - inserter.
ostream &operator<<(ostream &stream, three_d obj)
{
stream << obj.x << ", ";
stream << obj.y << ", ";
stream << obj.z << "\n";
return stream; // return the stream
}
// Get three dimensional values - extractor.
istream &operator>>(istream &stream, three_d &obj)
{
cout <<
"Enter X Y Z values, separating each with a space: ";
stream >> obj.x >> obj.y >> obj.z;
return stream;
}
int main()
{
three_d a(1, 2, 3);
cout << a;
cin >> a;
cout << a;
return 0;
}
----------------------------- clip ------------------------------------------
produced an executable with the size of 3692 bytes with my 'arm-linux-gnu'
(using glibc-2.1.2), 4052 bytes with my 'ppc-linux-gnu' (using glibc-2.1.1)
and 4412 bytes with my 'i486-linux-gnu' (using glibc-2.1.3) target cross-
compiler (under Win32).
The 'arm-linux-gnu-objdump -p' for the Linux/ARM-executable gives for the
used dynamic libraries (using 'ldd' isn't possible) :
----------------------------- clip ------------------------------------------
<snip>
Dynamic Section:
NEEDED libstdc++-libc6.1-2.so.3
NEEDED libm.so.6
NEEDED libc.so.6
NEEDED ld-linux.so.2
INIT 0x200052c
FINI 0x2000804
HASH 0x2000130
STRTAB 0x2000384
SYMTAB 0x20001e4
<snip>
----------------------------- clip ------------------------------------------
This shows the executable using the shared 'libstdc++' at runtime.
My conclusion is that somebody simply forgot to use the '--enable-shared'
while building the mentioned gcc-2.95.1. The 'objdump -p', when used for
the Linux/ARM executables should tell whether they use a shared 'libstdc++'
or not...
Cheers, Kai
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
More information about the crossgcc
mailing list