Package: g++
Version: 1:2.95.3-7
Severity: normal
Hi,
I just found out that some of the symbols pulled in from libgcc.a have odd
behaviour. If I write a simple program (foo.cc) like this:
int main()
{
int *x = new int;
return 0;
}
And compile like this:
$ g++ -fno-exceptions -fno-rtti -c foo.cc
And then link in two different ways:
$ g++ -s -o fooplus foo.o
$ gcc -s -o foo foo.o
I get very different files:
$ ls -l foo fooplus
-rwxrwxr-x 1 apenwarr apenwarr 28524 nov 7 18:20 foo*
-rwxrwxr-x 1 apenwarr apenwarr 3368 nov 7 18:20 fooplus
$ ldd foo fooplus
foo:
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
fooplus:
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
libm.so.6 => /lib/libm.so.6
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
Okay, so why is fooplus smaller? The ld -Map option for the non-c++ foo
binary tells us this:
Archive member included because of file (symbol)
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opnew.o)
foo.o (__builtin_new)
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(_eh.o)
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opnew.o) (__throw)
[...etc...]
Now, these files _aren't_ brought into fooplus, because fooplus is linked
with libstdc++. This reveals two potential problems:
- libstdc++ is linking with and then re-exporting libgcc.a symbols. My
understanding of libgcc.a is that it can change completely from one
version of gcc to the next, so these symbols might be completely invalid
for code generated by a different version of gcc. Thus, libstdc++ may
become arbitrarily incompatible with code generated by a different
compiler. If this is okay, then libgcc.a might as well be in a
libgcc.so, and we can link that when linking with gcc instead of g++;
if this is _not_ okay, we need to fix it so these symbols don't get
re-exported.
- libgcc.a was compiled with exception handling and rtti information,
which makes the new and delete implementations much more complicated
and is the main reason the code bloats so much when they're linked in.
Since I compiled with -fno-rtti and -fno-exceptions, I'm trying to
avoid that bloat. (In this case, it's for an embedded system where I
want neither exceptions, rtti, or STL, so I _have_ to link using gcc.)
Note that the first problem is unaffected by -fno-rtti and -fno-exceptions.
Unfortunately, I can't offer a good solution to these problems. Perhaps
someone upstream will know. I was just getting frustrated that the minimal
dynamically-linked C++ program on my system is 28k (and it gets bigger again
if I actually call 'delete'...)
Have fun,
Avery
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux insight 2.4.9 #1 Thu Nov 1 23:29:21 EST 2001 i686 unknown
Versions of the packages g++ depends on:
ii cpp 2.95.3-7 The GNU C preprocessor.
ii g++-2.95 2.95.4-0.01042 The GNU C++ compiler.
ii gcc-2.95 2.95.4-0.01042 The GNU C compiler.
ii libstdc++2.10- 2.95.4-0.01042 The GNU stdc++ library (development files)
ii libstdc++2.10- 2.95.4-0.01082 The GNU stdc++ library
