------- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 10:07 ------- Ok, it's not an LD bug. LD is doing the right thing, which in this case turns out to be filtering it out of the list of exports due to the version script.
In the 32-bit multilib, we have this version of std::string::reserve > $ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve > 00000000 t .text$_ZNSs7reserveEj > 00000000 T std::string::reserve(unsigned int) which is covered by this part of the version script: > # Names not in an 'extern' block are mangled names. > > # std::string [ ... snip ... ] > _ZNSs[67][j-z]*E[PRcjmv]*; In the 64-bit multilib, however, std::string::reserve has a different signature: > $ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve > 0000000000000000 t .text$_ZNSs7reserveEy > 0000000000000000 T std::string::reserve(unsigned long long) and that trailing 'y' doesn't match the '[PRcjmv]*' character class. Now, I haven't yet tracked down why 'unsigned int' in the 32-bit multilib has changed to 'unsigned long long' in the 64-bit multilib; it's a consequence of some 32-vs-64 difference in the w64 standard types no doubt, but it's definitely doing the wrong thing here, because the signature of the std:: function args is of course part of the ABI and I think we probably can't go changing the types of std:: function arguments like this. I'll try and track down where the ULL is coming from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
