This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> compatible?
> 
> 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
significantly.

> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]