Bug#118670: g++: libgcc.a symbols end up exported by shared libraries

[Avery Pennarun <apenwarr@insight.nit.ca>]

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