On 23/05/16 14:24, MM wrote:
> On 23 May 2016 at 12:53, Szabolcs Nagy 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
>>> -o -rdynamic Wl,-rpath,
>>>
>>> These are the errors I see (only in release, not in debug):
>>> ... [clone .constprop.79]: error: undefined reference to
>>> 'typeinfo for 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 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 market'
>>> V typeinfo for market
>>>
>>> 2. In RELEASE
>>> gcc-nm -C market.cpp.o | grep 'typeinfo for market'
>>> W typeinfo for 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
>
