This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gcc code bloat


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]