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@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 _______________________________________________ calligra-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/calligra-devel
