gold linker failing to resolve weak undefined symbol


I am experimenting with an inline strategy wherein I postpone inlining to link time rather than inlining at compile time, but I am facing runtime failure and wonder if anyone else saw this.

Here is my sample test case:

$ cat test.cpp


int main() {

std::stringstream ss;

ss << “hello”;



To test my inline strategy, I compile at O1 and use flto with gold plugin as below:

clang -O1 -flto -Wl,-fuse-ld=gold -static test.cpp –o test.exe

But the executable segfaults due to a weak undefined symbol:

Program received signal SIGSEGV, Segmentation fault.

0x00000000 in ?? ()

(gdb) bt

#0 0x00000000 in ?? ()

#1 0x000221e6 in std::basic_stringbuf<char, std::char_traits, std::allocator >::str() const ()

#2 0x00009020 in main ()

$ nm test.exe|grep _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag

w _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag

Note that the symbol value is null for the symbol _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag in the symbol table.

However, when I compile at O3 and use flto with gold plugin, the linker is able to resolve the symbol correctly and there is no runtime failure:

clang –O3 -flto -Wl,-fuse-ld=gold -static test.cpp –o test.exe

$ nm test.exe|grep _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag

00030139 W _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag

Has anyone seen this issue before? Could this be an issue with the gold linker?

Is it a bad design strategy to postpone inlining to link stage?



This was fixed by r216215