https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to palmer from comment #10) > After signing off last night I realized that none of that would work anyway, > though, as even with the same library on both ends users would end up with a > different mutex and thus races. So I think that one isn't worth worrying > about. Agreed. > I'm not > sure if folks are shipping clang-built libstdc++ anywhere (and if so, are They're not, and it's unsupported. Libstdc++ is part of GCC and must be built by GCC. > I guess I'm not really sure here: normally I'd say we're stuck with the > default being ABI compatible, but I don't know the rules in libstdc++. I'm > assuming that forcing the default to be mutex could still allow users who > want atomic to configure with --with-libstdcxx-lock-policy=atomic, so at Yup. > least there's a path forward. IIUC users will get link errors when moving > between the two flavors (the explicit template instantiations will have > different integer values), Not necessarily. The std::shared_ptr type isn't affected by that template parameter, only its base class is. So APIs defined in terms of the public std::shared_ptr type do not get linker errors if the private std::__shared_ptr type differs.
