This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO and undefined reference to typeinfo
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: MM <finjulhich at gmail dot com>, <gcc at gcc dot gnu dot org>
- Cc: <nd at arm dot com>
- Date: Tue, 24 May 2016 14:27:49 +0100
- Subject: Re: LTO and undefined reference to typeinfo
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CADsB1iCycw3vko0Ju1hWtMwa-5syfp3iyN_UDj5+HLcFX3REsA at mail dot gmail dot com> <5742EF4B dot 5090506 at arm dot com> <CADsB1iBB3LqFHKur-hvPTH3WCT6CO-SqS9auSJ-+3cvTRnCokg at mail dot gmail dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 23/05/16 14:24, MM wrote:
> On 23 May 2016 at 12:53, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> On 23/05/16 12:36, MM wrote:
>>> Hello,
>>>
>>> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
>>> GNU gold (version 2.25-17.fc23) 1.11
>>> I successfully link a executable in debug mode (-std=c++11 -g) but not in
>>> release mode (-std=c++11 -flto -O3). All sources are compiled with the same
>>> option. Shared libraries are used.
>>> The compiler driver is used to launch the final link line:
>>> /bin/c++ -std=c++11 -Wno-multichar -O3 -DNDEBUG -flto <listofOfiles>
>>> -o <executable> -rdynamic <listofsolibs> Wl,-rpath,<longlistofdirs>
>>>
>>> These are the errors I see (only in release, not in debug):
>>> ... [clone .constprop.79]: error: undefined reference to
>>> 'typeinfo for <ns1>::<ns2>::market [clone .lto_priv.1353]'
>>>
>>> Both the debug and release version of the object referencing this show the
>>> same with gcc-nm:
>>>
>>> U typeinfo for <ns1>::<ns2>::market
>>> Note this bit " [clone .lto_priv.1353]" is not in the symbol at all.
>>>
>>> This is what gcc-nm says for the object where the symbol is defined
>>> (market.cpp.o, which is part of libmarkets.so):
>>>
>>> 1. In DEBUG
>>> gcc-nm -C market.cpp.o | grep 'typeinfo for <ns1>::<ns2>::market'
>>> 0000000000000000 V typeinfo for <ns1>::<ns2>::market
>>>
>>> 2. In RELEASE
>>> gcc-nm -C market.cpp.o | grep 'typeinfo for <ns1>::<ns2>::market'
>>> 00000000 W typeinfo for <ns1>::<ns2>::market
>>> This is the one that fails.
>>> Given the versions of gcc and ld, the default behaviour for lto should be
>>> straightforward?
>>> Any ideas what's going on?
>>>
>>
>> typeinfo seems to be a weak object symbol
>> which is known to be broken with lto, so
>> this may be related to:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
>>
>
> Is it a workaround to not compile the referencing cpp and the referred
> cpp without lto, yet compile all the rest and link with lto?
> Otherwise, I'll turn off LTO until that bug is resolved.
it is not clear if this the same issue as pr692771,
so i think you should submit a bug report with
test code if possible.
>
> Thanks
>