Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Jakub Jelinek wrote:

> For branch I think this could be acceptable, but for trunk I really think
> we should do this on all architectures that have shared libgcc_s*.
> It is not just arm/sh that need this, but also e.g. ppc-linux (and maybe
> ppc64-linux), where libgcc.a only contains the out of line gpr/fpr register
> save/restores.
> 
> Something like (untested):
> 
> --- gcc.c	2009-06-11 13:24:15.000000000 +0200
> +++ gcc.c	2009-07-07 11:11:27.664079777 +0200
> @@ -1733,11 +1733,11 @@ init_gcc_specs (struct obstack *obstack,
>  		"}"
>  #ifdef LINK_EH_SPEC
>  		"%{shared:"
> -		"%{shared-libgcc:", shared_name, "}"
> +		"%{shared-libgcc:", shared_name, " ", static_name, "}"
>  		"%{!shared-libgcc:", static_name, "}"
>  		"}"
>  #else
> -		"%{shared:", shared_name, "}"
> +		"%{shared:", shared_name, " ", static_name, "}"
>  #endif
>  #endif
>  		"}}", NULL);

  We've been doing this in the cygwin port for some time by defining
SHARED_LIBGCC_SPEC in a tm.h file.  It seems to work OK for us.

> Most of libgcc.a is sane and on targets with visibility support
> makes all symbols hidden anyway.

  Please be careful to avoid any "all-the-world's-an-ELF"isms!

> The major exception here are the dfp bits, here I'd think we should remove
> them from libgcc.a and put into libgcc_dfp.a or something similar
> (and have libgcc_dfp.so too).

  Argh.  We don't have DFP on cygwin yet but probably want to add support
soon.  What's the issue with this?  Shouldn't those kind of simple maths
routines be in the shared libgcc and linked from there anyway?

    cheers,
      DaveK