https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> --- Author: redi Date: Mon Jul 29 14:27:19 2019 New Revision: 273878 URL: https://gcc.gnu.org/viewcvs?rev=273878&root=gcc&view=rev Log: PR libstdc++/51333 Define recursive_init_error constructor non-inline The recursive_init_error class is defined in a header, with an inline constructor, but the definition of the vtable and destructor are not exported from the shared library. With -fkeep-inline-functions the constructor gets emitted in user code, and requires the (non-exported) vtable. This fails to link. As far as I can tell, the recursive_init_error class definition was moved into <cxxabi.h> so it could be documented with Doxygen, not for any technical reason. But now it's there (and documented), somebody could be relying on it, by catching that type and possibly performing derived-to-base conversions to the std::exception base class. So the conservative fix is to leave the class definition in the header but make the constructor non-inline. This still allows the type to be caught and still defines its base class. User code can no longer construct objects of that type, but that's not something we need to support. PR libstdc++/51333 * libsupc++/cxxabi.h (__gnu_cxx::recursive_init_error): Do not define constructor inline. * libsupc++/guard_error.cc (__gnu_cxx::recursive_init_error): Define constructor. * testsuite/18_support/51333.cc: New test. Added: trunk/libstdc++-v3/testsuite/18_support/51333.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/cxxabi.h trunk/libstdc++-v3/libsupc++/guard_error.cc
