Re-introduce the possibility to define CPPU_LEAK_STATIC_DATA. This
time use it to bypass just the assertions that check that the type
description counts really are zero at the end of the
TypeDescriptor_Init_Impl destructor.
Add more informative debugging printout of which counts are non-zero.
Define CPPU_LEAK_STATIC_DATA for x64 Windows for now. But we do get
the same assertions also on x86 Windows if cppu is built with
OSL_DEBUG_LEVEL>1.
We do print out a message if struct size verifications fail. That is
enough. No point in printing out the same
> sizeof(AlignSize_Impl) = 16
> sizeof(M) = 8
> sizeof(N) = 12
etc messages every time a cppu-using program is run and cppu has been
built for debugging.
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
This reverts commit 146e2fbca20f5cba3410d3d042ae6222a565dd7e.
The workaround is has to be present in libreoffice-3-3, but we do not want to
have it in master, so that eventually it is fixed in the end :-)
Reintroduce the horrible CPPU_LEAK_STATIC_DATA hack used in OOo 3.2.1,
but only for Windows builds. No idea what causes the crash. See
fdo#31494. Don't know if this hack has some bad consequences then,
i#107490 seems to say so.
