PATCH: PR ada/16592: Ada tools don't use the newly built shared libraries

[Olivier Hainque]

Arnaud Charlet wrote:
> Also adding Olivier in the discussion, since he made the change to raise.c
> Olivier, could you review this discussion and provide your comments ?

 The first bit of information is that raise.c using _Unwind functions is not
 at all new.

 raise.c essentially contains the eh personality routine for Ada and has
 always used at least basic functions like _Unwind_GetIP or _Unwind_SetGR to
 probe/adjust the unwinding context.

> > With http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02214.html
> > 
> > and a newer binutils, anything which calls unwind functions will
> > be linked against libgcc_s.so.1.

> What is the reason for this change ?

> Is there a way to link statically when needed ?

 IIUC, only some default behavior has changed, and the rationale for that
 change is a bit unclear to me. It is for sure intended to fix a bug, and
 command line options are available to force another behavior. Here is the
 comment from the patch submission mentioned above:

   << Alan recently implemented support for conditional linking of shared
      libraries.  The follwoing patch is the GCC side of the needed changes.
      Without it for example gcc 3.4+ compiled NPTL C programs using
      pthread_cleanup_{push,pop} will not handle cancellation properly.  This
      patch just changes the default behaviour, when neither -static-libgcc
      nor -shared-libgcc is specified.  The program or shared library will be
      linked against libgcc_s if EH is used and just against libgcc.a if not.
   >>

 I don't think it is as abrupt as "as soon as you have eh, you must link
 with libgcc_s". I'm not yet clear if the new default is a real annoyance
 and what alternate paths are available is the problematic cases.

 What HJ has mentioned:

  << You can avoid it on Linux with similar approach used in glibc. It
     defines its own local unwind functions. It does dlopen libgcc_s.so.1
     and dlsym the real one, then call it when the local unwind function
     is called.
  >>

 does not sound very appealing to me, because multiplying the definitions of
 base functions seems like asking for troubles. The existing case with thread
 locking routines vs targets not supporting weak symbols vs dummy symbols
 somtimes in OS libs and sometimes not is an example of where we don't want
 to go too often IMO.