versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 01:52:07PM -0700, Mark Mitchell wrote:
> >
> >If we are building a shared library with DT_NEEDED pointed to the
> >unwind library called "libgcc_s.so.1", how can another compiler use
> >their unwind library, saying libmyunwind, with this DSO? If the C++
> >ABI covers unwind with shared library and executable, it should also
> >specify how the unwind library should be handled at link time as well
> >as at run time.
> > 
> >
> The ABI says:
> 
> An implementation shall place its standard support library in a DSO 
> named |libcxa.so| on Itanium systems, or in auxiliary DSOs automatically 
> loaded by it.  It shall place implicit compiler support in a library 
> separate from the standard support library, with any external names 
> chosen to avoid conflicts between vendors (e.g. by including a vendor 
> identifier as part of the names).
> 
> The reference to "Itanium" is accidental.
> 
> GCC, for whatever reason, has never provided libcxa.so.  That library 
> should contain all of the C++ ABI stuff, and should be *completely 
> interchangeable* between vendor implementations.  The complete set of 
> interfaces and the behavior of those interfaces is specified by the C++ 
> ABI.  It should not matter whose libcxa.so you get; if it does matter 
> either your program or the libcxa.so implementation you're using has a bug.
> 

So it is almost totally a run-time issue. You can link against a dummy
libcxa.so if you want. It is the one picked up by the dynamic linker
counts.

> Since GCC has never provided this library, there are going to be 
> challenges here.
> 
> The first step is to undo the versioning mistake.  That's a sine qua non 
> for anything else.  After that, someone should implement libcxa.so.  
> Probably, libgcc will need to depend on it, since existing programs 
> expect libgcc to provide these interfaces.

Where do those versioned definitions for backward compatibilty come
from? Should we consider libgcc_s.so.2?


H.J.