This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO and version scripts
- From: Alan Modra <amodra at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Ulrich Drepper <drepper at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 5 Aug 2014 14:27:28 +0930
- Subject: Re: LTO and version scripts
- Authentication-results: sourceware.org; auth=none
- References: <CAOPLpQfvs_E8rfHHAF18t+bGxc5+-Rtg7dAUv+oTpws-wt3wuw at mail dot gmail dot com> <CAFiYyc0EdAgd56Ja5bBGFdfJ5NMxb84NwnDw+sJ1z8fmXwakmA at mail dot gmail dot com>
On Mon, Jul 07, 2014 at 11:04:17AM +0200, Richard Biener wrote:
> On Mon, Jun 30, 2014 at 2:35 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> > Using LTO to create a DSO works fine (i.e., it performs the expected
> > optimizations) for symbols which are marked with visibility
> > attributes. It does not work, though, when the symbol is not
> > restricted in its visibility in the source file but instead is
> > prevented from being exported from the DSO by a version script (ld
> > --version-script=FILE).
> >
> > Is this known? I only found general problems related to linker
> > scripts although version script parameters do not cause any other
> > failures.
>
> Yes, I've run into this as well. IMHO the issue is that the linker(s)
> do not process the linker script "properly" when handing off
> the resolution data to the linker plugin. So it's a linker bug AFAIU.
What version linker? In particular, do you have the fix for PR12975?
--
Alan Modra
Australia Development Lab, IBM