More on shared libgcc

["H . J . Lu" <hjl at lucon dot org>]

I have modified linker so that it will load symbols from files appear
in DT_AUXILIARY. It seems to work ok.

However, it may not solve all the problems alone. To generate an
executable, gcc does

# gcc -o aout crt1.o crti.o crtbegin.o *.o ... -lgcc -lc -lgcc crtend.o crtn.o

If there are any references to symbols in libgcc from files between
crtbegin.o and -lgcc, libgcc will be used regardless if they are
defined in libc.so or not. That means if there is no libgcc.so, those
references will result in defintions of those symbols in aout. But I
don't think any C codes are affected. We can add new functions to
libgcc without breaking any binaries. So far, I guess only C++ codes
are affected. It may be solved by shared libstdc++ built with
-Wl,--auxiliary,libgcc.so.x. That means libgcc.a will only be used for
symbols not in libgcc.so.x. But there are no explicit dependencies on
libgcc.so.x. But the binary will fail to run if the new functions used
to build are not in the install libgcc.so.x. It is the same as glibc
when we add new functions and a binary uses them. If you try to run
it on an older glibc, you will get undefined symbols.

I put my patch at

http://www.lucon.org/binutils/tmp/binutild-auxiliary.patch

But I don't know if it is really needed at all. I am also still not
convinced that we need libgcc.so. We need to come up with some test
cases first.


H.J.