Hi,

tl;dr how to avoid crashes if libQtUiTools.a is linked multiple times into a 
process?


You use at least one of kross, kjsembed, or plasma in your 
application/lib/module and possibly also directly libQtUiTools yourself?

Then bugs.kde.org shows that chances are that you have seen crashes with this 
in the backtrace:
#6  0xb5320313 in 
QFormInternal::domPropertyToVariant(QFormInternal::QAbstractFormBuilder*, 
QMetaObject const*, QFormInternal::DomProperty const*) () from XXX 

where XXX could be libplasma, libkjsembed, krossmoduleforms or your own 
binary/lib/module.

For historic reasons libQtUiTools is a static lib, not a shared, and there has 
been no work to change that, compare https://bugreports.qt-project.org/browse/QTBUG-437

A few days ago I looked into Kross scripts in Calligra the first time, only to 
ran into this problem, as reported to my distri here: 
https://bugzilla.novell.com/show_bug.cgi?id=819437

As can be read in that report, I saw in my backtrace that QFormInternal 
methods are once called in krossmoduleforms.so, once in libkjsembed.so.4 in 
the very same call stack, while they surely should be only done in a single 
place. And Hrvoje Senjan found that linking libQtUiTools.a into the own code 
without Bsymbolic-functions flag seems to avoid the crashes.

So, anyone with more clue than me WRT symbols from static libs and the 
Bsymbolic-functions linker flag who could tell if that indeed should fix such 
problems if code from the same static lib is arriving multiple times in the 
same process via different libs/modules?

If so, should all the places where ${QT_QTUITOOLS_LIBRARY} is linked in 
kdelibs and elsewhere get a blocker to the Bsymbolic-functions flag?
How would that be done, to force this flag to be unset?

What about other non-GCC platforms/compilers, is there a similar problem?

Cheers
Friedrich