Re: Bug#118670: g++: libgcc.a symbols end up exported by shared libraries
> 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.
Why do you think this is a problem? libstdc++ is part of gcc, so
whenever gcc changes, libstdc++ changes as well. In fact, the
libstdc++ API likely changes much more frequently than the libcc API.
> Thus, libstdc++ may become arbitrarily incompatible with code
> generated by a different compiler.
That won't happen. libgcc never changes in a way that an existing API
gets a different semantics. The only changes to libgcc are
- a new API is introduced (using different entry point names), or
- an existing API is not use any longer by gcc, or
- an API that hasn't been used for a while is dropped.
> 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.
In fact, gcc 3 builds libgcc as a shared library (libgcc_s.so.1), so
that part of your report appears to be fixed already.
> - 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.
The C++ standard mandates this complexity, as operator new *must*
throw bad_alloc. It does even when you compile with
-fno-exceptions. This is not a bug; please see the documentation of
-fexceptions for details.
> (In this case, it's for an embedded system where I want neither
> exceptions, rtti, or STL, so I _have_ to link using gcc.)
In this case, and if you really want that new doesn't throw
exceptions, you need to supply your own version of libgcc. Given that
the source is available, this is not too difficult.
Notice that merely compiling cp/new1.cc with -fno-exceptions won't
work, since there really is EH code in this file.
Regards,
Martin
Reply to: