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] |
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] |