hidden symbol '_ZNSt12__sso_stringC1EPKcm' is not defined locally

[John Steele Scott]

On 27/11/17 16:18, John Steele Scott wrote:
> I have a project we are currently building on Centos 7 with the devtoolset-4 build of GCC 5. I'm trying to upgrade it to use GCC 7 from devtoolset-7.
> The build generates a silly number of shared libraries in a fairly deep dependency tree. Some of the libraries are failing to link with:
> 
> /opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld.gold: error: hidden symbol '_ZNSt12__sso_stringC1EPKcm' is not defined locally
> 
> Not hugely informative. I hacked gold to print the object where that symbol comes from (it's in a handful of shared objects . . . this project is shared objects all the way down), but it looks like actually this symbol is *not* defined locally:
> 
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
> ...
>    664: 0000000000027b10    15 FUNC    GLOBAL DEFAULT   12 _ZNSt12__sso_stringC1EPKcm
> 
> Ultimately this symbol is defined in the libstdc++_nonshared.a library that is used to provide the newer C++ symbols that are not in the base Centos' GCC 4.8.
> 
> Interestingly, in devtoolset-4 this symbol *was* hidden:
> 
> jscott@jscott-centos7:/tmp$ readelf --wide --syms /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libstdc++_nonshared.a | grep _ZNSt12__sso_stringC1EPKcm | grep -v UND
>    117: 0000000000000000    15 FUNC    GLOBAL HIDDEN    62 _ZNSt12__sso_stringC1EPKcm
> 
> Now it is not:
> 
> jscott@jscott-centos7:/tmp$ readelf --wide --syms /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++_nonshared.a | grep _ZNSt12__sso_stringC1EPKcm | grep -v UND
>     35: 0000000000000000    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__sso_stringC1EPKcm
> 
> 
> Since devtoolset-7 sets _GLIBCXX_USE_DUAL_ABI=0, my read of stdexcept is that std::__sso_string should just be a typedef to std::string. So what's pulling the SSO string? Other references to it in libstdc++_nonshared.a are from cow-stdexcept.o and system_error48.o. The former looks likely to be why we would be getting it - presumably many of the STL functions which throw exceptions will cause that to be required. Working around this by avoiding such calls (e.g. use bitset[n]=x instead of bitset.set(x)) is not really sustainable.
> 
> So far my attempts to recreate this in a small example (only a couple of shared libraries) haven't worked.
> 
> In a couple of instances I was able to get rid of the errors by replacing a devtoolset-4-built library with one built with the native GCC 4.8. But that doesn't seem to be globally applicable.
> 
> Any ideas on what is going on here?
> 
> Cheers,
> 
> John
> 
> 

I managed to boil this down to a small example: https://bugzilla.redhat.com/show_bug.cgi?id=1519073

Cheers,

John