[Patch] [libstdc++] [C++0x] Export std::string base object move constructor.

["Adam Butcher" <dev dot lists at jessamine dot co dot uk>]

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

Attachment: 0001-libstdc-v3-C-0x-Export-std-string-base-object-move-c.patch
Description: Binary data