not bug, just simple question: why we can not wrap libstdc++ and libgcc_s?

[ifquant]

just for curious, because there are may different size struct in arm and x86?

[ptitSeb]

It's mainly because C++ ABI have data structure along intermixed with function pointer (for the Virtual Tables and RTTI). Also, it's not specified on the standard how they are done. Basicaly, that means a lot of work and new tools to develop, so, for now, I have just decide to les c++ library emulated.

[ifquant]

It's mainly because C++ ABI have data structure along intermixed with function pointer (for the Virtual Tables and RTTI). Also, it's not specified on the standard how they are done. Basicaly, that means a lot of work and new tools to develop, so, for now, I have just decide to les c++ library emulated.

@ptitSeb thanks . i found for wraplib like liGLU.so libSDL2_mixer-2.0.so.0, libsmpeg2-2.0 liialure.so libxslt.so , ldd -r these lib, libstdc++ will be depended. it means ld.so will load libstdc++ under dlopen while box64 will load libstdc++ in self mmaped space. it will be a problem? or when it's will be a problem?

[ptitSeb]

Those libs might use libstdc++ internaly, but they are C libs and doesn't expose any libstdc++ object, so there is no problem. The libsstdc++ that will be mounted is the native one, and it will be invisible to the emulated program.

[ifquant]

@ptitSeb thanks. so if any native lib if it expose some libstdc++ object, it may be dangerous.
if c libs alter native libstdc++ 's internal global status, but not influent in emulated libstdc++,
it also dangerous.

Those libs might use libstdc++ internaly, but they are C libs and doesn't expose any libstdc++ object, so there is no problem. The libsstdc++ that will be mounted is the native one, and it will be invisible to the emulated program.

[ptitSeb]

Yes, because there will be 2 different libstdc++ in memory, the native one and the emulated one. Like if you were using two different version at the same time.