PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 08:22:41AM -0700, David Mosberger wrote:
> >>>>> On Wed, 21 Apr 2004 07:35:54 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote:
>   >> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts
>   >> libunwind.a in libgcc_s.so.1. The test result is at > We can do
>   >> it on ia64 since PIC is default on ia64.
> 
>   >> IA-64 code is PIC by default.  However, it is not true that
>   >> static library code and shared library code are the same.  There
>   >> are differences because of the IA-64 ABI, for instance, the rules
>   >> that say "own" data can be put in the small data section, but
>   >> what qualifies as "own" data is different for shared libraries
>   >> and static libraries.  This stuff is controlled by the -fpic

If the small data section is the only difference, we may get lucky
with libunwind.

>   >> option.  You must use -fpic for all code that goes into a shared
>   >> library.  Note: -fpic has always meant compile this code for
>   >> shared libraries, this is even true on systems like IA-64 where
>   >> code is PIC by default.  There is no guarantee that code in
>   >> libunwind.a was compiled with -fpic.  I don't see how this can
>   >> work.
> 
>   HJ> We can always require to compile the static libunwind library
>   HJ> with -fpic.
> 
> I really do not think this is the right approach.
> 

The ideal solution is to do what Solaris does. That is linker and
dynamic linker work together to support moving a definition from one
DSO to another, transparently. But it is not an option today.

Given that we should provide 100% backward binary compatibility, which
was the problem to begin with, our choices are very limited.


H.J.