This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO and undefined reference to typeinfo


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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]