Re: Question about very old patch

[Geoff Keating <geoffk at cygnus dot com>]

Marc Espie <Marc.Espie@liafa.jussieu.fr> writes:

> Mon Dec  4 22:17:37 1995  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * gcc.c (LIBGCC_SPEC): Do link with libgcc when -shared.
>         * alpha.h (LIBGCC_SPEC): Remove.
>         * linux.h (LIBGCC_SPEC): Remove.
>         * svr4.h (LIBGCC_SPEC): Remove.
>         * i386/t-crtpic (TARGET_LIBGCC2_CFLAGS): Use -fPIC.
>         * t-pa (TARGET_LIBGCC2_CFLAGS): Use -fPIC.
>         * sparc/t-sunos41 (TARGET_LIBGCC2_CFLAGS): Use -fPIC.
>         * sparc/t-sol2 (TARGET_LIBGCC2_CFLAGS): Use -fPIC.
>         * configure (i386-linux): Use i386/t-crtpic.
> 
> 
> I know, this is positively ancient, but could you outline what prompted
> that decision, whether it still makes sense, etc ?

There are two parts to the patch.

The first part causes gcc -shared to link with libgcc.  There are two
reasons for this:

1. Generally speaking, if a shared object uses a routine, a library
   that supplies that routine should be on the link line.  The
   exception is for routines which are known to be provided by the
   application, and even in that case the shared object should probably
   be linked to the application (by specifying it on the link line
   too)---I know this doesn't work in many circumstances.

2. It's necessary to ensure that the routines are always available to
   the shared object if:

   - the application is not built with gcc;
   - the application was linked against an older version of the shared object
     which used a different subset of the routines in libgcc;
   - the shared object is dynamically loaded into a statically linked
     program which doesn't export any routines from libgcc.


The second part switches -fPIC on because otherwise the first part
will create shared libraries with relocations in .text, which are less
efficient.  It's OK to link PIC code into non-PIC objects, but costly
to link non-PIC code into PIC objects.

-- 
- Geoffrey Keating <geoffk@cygnus.com>