[PATCH] PR libstdc++/51333 Define recursive_init_error constructor non-inline

[Jonathan Wakely]

On 29/07/19 15:27 +0100, Jonathan Wakely wrote:
>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.

Actually they could never construct them, because the vtable wasn't
exported. So making the constructor non-inline has no semantic effect.
The only difference is that throwing a recursive_init_error when
static init fails will not inline the constructor, which is fine.

So I see no reason to delay backporting this, and will do so for the
upcoming 9.2 release.