There are no details here about how it crashes, backtraces etc.
One possible thing could be that some C++ symbols really ought to be always
exported.
Say if you hide using version script
_ZZN9__gnu_cxx20__common_pool_policyINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
and
_ZGVZN9__gnu_cxx20__common_pool_policyINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
and then allocate some object using STL allocator in one shared library and
destroy it in a different library, you lose, as here libstdc++ relies on ODR.
Similarly with other _S_pool variable objects. Also, if you use RTTI, libstdc++
uses simple pointer comparison for RTTI checks; see
/usr/include/c++/4.0*/typeinfo header.
If you hide the typeinfo symbols (I think these are _ZTI* ones) and try to use
RTTI in one shared library on an object created in another shared library, RTTI
might give wrong answers.
There are no details here about how it crashes, backtraces etc. gnu_cxx20_ _common_ pool_policyINS_ 6__poolELb1EE11 _S_get_ poolEvE7_ S_pool _gnu_cxx20_ _common_ pool_policyINS_ 6__poolELb1EE11 _S_get_ poolEvE7_ S_pool c++/4.0* /typeinfo header.
One possible thing could be that some C++ symbols really ought to be always
exported.
Say if you hide using version script
_ZZN9__
and
_ZGVZN9_
and then allocate some object using STL allocator in one shared library and
destroy it in a different library, you lose, as here libstdc++ relies on ODR.
Similarly with other _S_pool variable objects. Also, if you use RTTI, libstdc++
uses simple pointer comparison for RTTI checks; see
/usr/include/
If you hide the typeinfo symbols (I think these are _ZTI* ones) and try to use
RTTI in one shared library on an object created in another shared library, RTTI
might give wrong answers.