Hi, I found that with the latest GCC 4.6.0 release candidate, dynamically linking against libstdc++ fails for client code that expects to move an object derived from std::string. The move constructor (either explicitly specified or compiler generated) of such a class fails to link in the std::string base constructor yielding the following:
undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)' Explicitly moving an instance of std::string not used as a base via std::move works fine. Previously I had worked around this by defining _GLIBCXX_EXTERN_TEMPLATE=-1 but that no longer works with the GCC 4.6.0 library snapshot made available yesterday so I looked into it further. Forcing the linker to generate unmangled diagnostics via -Wl,--no-demangle and subsequently using nm on libstdc++.so revealed the issue. undefined reference to `_ZNSsC2EOSs' >From nm it is clear that this symbol is defined but is internal to the text section (t) rather than weak and externally visible (W). The complete object move constructor (C1) is externally visible as expected which is why a basic string move works. 00091dc0 W _ZNSsC1EOSs 00091dc0 t _ZNSsC2EOSs After a bit of poking around with nm in various objects I determined that the baseline_symbols files define what should be exported. The following grep+sed combo adds the necessary export for any architecture that exports the C1 constructor symbol. grep _ZNSsC1EOSs libstdc++-v3/config/abi/post -R -l | xargs sed -i.bak '/_ZNSsC2EPKcRKSaIcE/ iFUNC:_ZNSsC2EOSs@@GLIBCXX_3.4.14' The result is attached as a patch against 4.6.0 20110321 (prerelease). Cheers Adam
0001-libstdc-v3-C-0x-Export-std-string-base-object-move-c.patch
Description: Binary data
