This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Abort in elflink.c: elf_link_check_versioned_symbol
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 03 Sep 2009 12:15:27 +0100
- Subject: Re: Abort in elflink.c: elf_link_check_versioned_symbol
- References: <1251281400.4775.15.camel@e200593-lin.cambridge.arm.com> <m3d46i4o49.fsf@google.com> <1251895757.8812.97.camel@e200593-lin.cambridge.arm.com> <m3y6oxia54.fsf@google.com>
- Reply-to: ramana dot radhakrishnan at arm dot com
On Wed, 2009-09-02 at 09:28 -0700, Ian Lance Taylor wrote:
> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes:
>
> >> > The symbol for which this abort happens is
> >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc
> >> > ++.so. Looking at this symbol in libstdc++.so, I can see that this is
> >> > versioned and weak as below but the actual symbol doesn't appear in the
> >> > shared object.
> >> >
> >> >>From the Symbol Table of libstdc++
> >> >
> >> > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11
> >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4
> >>
> >> That is a real symbol definition. It merely happens to be marked weak.
> >
> > Fair enough. If this is a real symbol definition and happens to be just
> > marked weak , then shouldn't all references resolve to this symbol.
>
> Normally yes, but based on the code path you show below the symbol has
> been forced to be local. That is, you are using a version script which
> forces this symbol to be local and therefore not visible to shared
> libraries.
Thanks for looking at this.
I'm not clear what the behaviour here should be - If this symbol is
defined in libstdc++.so and none of the object files / archive files
being linked in override it, why should it be marked as local (inspite
of the version script telling it to do so ) ?
My understanding was that local:* in a version script would apply to all
the symbols in the object files that were being linked in and not the
symbols defined in the shared libraries. Is that correct ?
> should simply return FALSE. You've demonstrated that this case can
> arise when a version script is used.
Simply returning a FALSE here causes a linker error message
/home/ramrad01/install-arm-binutils-trunk/bin/ld: gamma: local symbol
`std::basic_string<char, std::char_traits<char>, std::allocator<char>
>::basic_string<__gnu_cxx::__normal_iterator<char*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > >
>(__gnu_cxx::__normal_iterator<char*, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
__gnu_cxx::__normal_iterator<char*, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >, std::allocator<char>
const&)' in libs/libLLVMSupport.a(CommandLine.o) is referenced by DSO
/home/ramrad01/install-arm-binutils-trunk/bin/ld: final link failed:
Nonrepresentable section on output
I'm working on getting a smaller testcase yet
cheers
Ramana