This is the mail archive of the
mailing list for the GCC project.
Re: versioning of _Unwind_*() symbols
On Tue, 2004-04-20 at 16:51, David Mosberger wrote:
> I do understand that versioning may make sense in _general_, but we're
> talking about the C++ _ABI_ here. If it's not _binary_ compatible,
> then it's simply not compatible. No?
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
We have incidentally found a number of bugs in the C++ ABI simply by
comparing the HP, Intel, and GNU C++ compilers against each other. Some
of these problems have required compiler changes. Some of them have
required C++ ABI changes. I think all of these compilers are known to
have at least one bug that prevents them from being fully compliant, and
some (e.g. the HP one) may never be fixed, because of backwards
There is also the issue that we have extensions to the C++ ABI, as we
ran into problems making C++ exceptions work with thread cancellation.
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
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.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com