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
