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 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.

Thanks


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