Calligrastage 2.9.8/Mac : dynamic_cast error message

[Friedrich W. H. Kossebau]

Am Donnerstag, 15. Oktober 2015, 22:43:14 schrieb René J.V. Bertin:
> Hi,
> 
> Running a quick test of CalligraStage 2.9.8 on OS X 10.9, I see this error
> in my system.log:
> 
> Oct 15 22:35:09 Portia.local calligrastage[80756]: dynamic_cast error 1:
> Both of the following type_info's should have public visibility.  At least
> one of them is hidden. 19KoSharedLoadingData, 23KoTextSharedLoadingData.
> 
> Demangling:
> 19KoSharedLoadingData -> "KoSharedLoadingData"
> 23KoTextSharedLoadingData -> "KoTextSharedLoadingData"
> 
> I've been seeing similar messages for some Akonadi classes, but have never
> been able to figure out neither how to fix the code, nor if anything
> actually doesn't work because of this.
> 
> Maybe someone here has an idea?

No idea, but curious now.

KoSharedLoadingData is a header only class in libflake, not tagged for symbol 
export, with virtual destructor.
KoTextSharedLoadingData is a normal class in libkotext with separate source 
file compiled into libkotext, with class tagged for symbol export.

Quick googling hints OSX/LLVM* see some issue here.
http://stackoverflow.com/questions/27878186/dynamic-cast-fails-depending-on-os-version

*Message seems to be from https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp

As you said you saw this with Stage, while there are also dynamic_casts 
between both in libkotext, there is also one in 
KPrPlaceholderTextStrategy::loadOdf().

On my system with gcc version 5.1.1 it seems that does not result in a 
problem, e.g. libcalligrastageprivate has the typeinfo for KoSharedLoadingData 
created locally (and gets the one for KoTextSharedLoadingData from the linked 
libkotext):

koder at klux:~> nm -C 
System/opt/calligra3/lib64/libcalligrastageprivate.so.15.0.0 | grep 
SharedLoadingData
                 U KoTextSharedLoadingData::paragraphStyle(QString const&, 
bool) const
0000000000326298 d typeinfo for KoSharedLoadingData
                 U typeinfo for KoTextSharedLoadingData
00000000000e8e10 r typeinfo name for KoSharedLoadingData

Possibly LLVM treats things differently here, e.g. by not creating the 
typeinfo locally for the header-only class. No idea if that is right or wrong.

A workaround/fix might be to make KoSharedLoadingData a normally exported 
class with implementation of constructor/destructor inside libflake?

Cheers
Friedrich