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

[Adam Butcher]

On Tue, March 22, 2011 1:39 pm, Jakub Jelinek wrote:
> On Tue, Mar 22, 2011 at 01:10:14PM -0000, Adam Butcher wrote:
>> 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).
>
> That's not the patch to export it, baseline_symbols.txt is just
> for testing the ABI.
> Furthermore, you can't add new symbols to GLIBCXX_3.4.14, which has
> been already in gcc 4.5 and released almost a year ago, and lastly,
> std::wstring has the same problem.
>
Ah right.  Thanks for the clarifications.  I had actually modified
locally my:

  ../build/gcc-4.6.0/i686-pc-linux-gnu/libstdc++-v3/src/libstdc++-symbols.ver

file in my build directory which is what in fact made my build work.  I
had assumed incorrectly that this was generated for a particular target
from the baseline_symbols files as that was the only place that I found
the C1 constructor symbol reference.

In my haste I had missed the last line from git grep

  libstdc++-v3/config/abi/pre/gnu.ver:    _ZNSsC1EOSs;

which, from your patch below (and is now obvious that it is in fact the
exact content of the file I manually edited), is the true source for the
symbols.ver file in the build dir!

Had I have seen this previously the appropriate line would have been in
my patch.  The fact remains though that my patch would have still been
abusing the versioning completely!

> So, if Benjamin or other libstdc++ maintainers want it fixed for
> 4.6, you want a patch like attached, plus some testcases for both
> std::string and std::wstring.
>
Fair enough.  So I currently have an abused libstdc++ that claims that
the base object move ctor for std::string is in 3.4.14 when it is not -
3.4.14 has been released already.  Get it.

I had thought about wstring but was it was not necessary to build our
tree so I thought that an minimal incremental change might be
acceptable.

Here's a simple test program for both string types.  Currently this
fails to link the wstring ctor on my build for the expected reason.  It
will work as soon as I apply your patch.

   #include <string>

   template <typename C>
   class another_string : std::basic_string<C>
   {
   public:
      another_string() : std::basic_string<C>() {}
      another_string(another_string&& s)
                       : std::basic_string<C>(std::move(s)) {}
   };

   template <typename C>
   another_string<C> get() { another_string<C> s; return s; }

   template <typename C>
   void use(another_string<C>) { }

   int main()
   {
      use(std::move(get<char>()));
      use(std::move(get<wchar_t>()));
   }

Cheers
Adam