This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- From: Matthias Klose <doko at ubuntu dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Matthias Klose <doko at ubuntu dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Paolo Carlini <paolo dot carlini at oracle dot com>, GCJ-patches <java-patches at gcc dot gnu dot org>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- Date: Mon, 13 Jul 2009 09:12:27 -0400
- Subject: Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- References: <4A530F5C.4040500@ubuntu.com> <20090707091425.GB4462@tyan-ft48-01.lab.bos.redhat.com>
Jakub Jelinek schrieb:
> On Tue, Jul 07, 2009 at 11:03:24AM +0200, Matthias Klose wrote:
>> Use a linker script to link with -lgcc_s -lgcc on arm-linux, which allows the
>> arm-linux target to run the testsuite without regressions with the patch for the
>> exception propagation support [1] enabled.
>>
>> The approach taken is the same as used on the sh-linux configuration.
>>
>> Tested on the 4.4 branch without regressions (c, c++, fortran, objc, obj-c++),
>> the trunk currently fails to build for unrelated reasons [2]
>>
>> Ok for the branch (and for the trunk after it bootstraps again)?
>
> 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);
>
> Most of libgcc.a is sane and on targets with visibility support
> makes all symbols hidden anyway.
this doesn't seem to work together with -nostdlib, e.g. how libstdc++ is linked
(libstdc++ ends up with undefined symbols from libgcc). Current libtool has it's
own idea about linking with libgcc, and doesn't link with -lgcc (explicitely
removing it from the command line if it's there). So do we have to change
libtool at the same time to support linking with both libgcc_s and libgcc?
Matthias