This is the mail archive of the
mailing list for the GCC project.
Re: versioning of _Unwind_*() symbols
On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote:
> Why does glibc bother to versions symbols when they are all binary
> The answer is that while the intent is for everything to be binary
> compatible, we occasionally find bugs, and the symbol versioning allows
> us to fix bugs without losing backwards compatibility. Also, standards
> occsionally change, and this presumably allows for some compatibility
> across standards.
The latter issue is not a problem here. Presumably, the former isn't
either - a standard has to take the pre-symbol-versioning approach of
simply renaming functions when their signatures or behavior change
> What is wrong with putting the symbols back in libgcc_s.so? If you link
> with libunwind before libgcc, programs will use the libunwind versions
> won't they?
Dubious - behavior with both versioned and unversioned definitions
present can be pretty random.
> Maybe the issue is that system libraries that were linked again libgcc
> will still use the libgcc version? That gets us back to the issue I
> mentioned before, which is that this is really a system packaging issue,
> not a libgcc vesioning issue. If a linux distro ships with libunwind as
> a standard package, then everything is OK. If libunwind is an add on
> package, then we can't replace the versioned libgcc functions, we can
> only replace the internal unversioned functions.
The issue that I see is that code linked against libgcc's
implementation of the C++ ABI can not be used with anyone else's
implementation of the C++ ABI. If that is not binary incompatibility,
then what do you think is? Putting explicit "GCC_3.x" identifiers on
the symbol reference means that the binary demands GCC's implementation
and demands that it come from libgcc_s.so.1.
MontaVista Software Debian GNU/Linux Developer