Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Friedrich W. H. Kossebau]

Hi Windows-Warriors,

tl;dr how to prevent symbol clashes with static libs multiple times in the 
same process with the supported windows linkers?


See http://lists.kde.org/?t=136829863100001&r=1&w=2 for the complete 
conversation on kde-core-devel so far, here the most relevant parts:

Am Samstag, 11. Mai 2013, 20:53:46 schrieb Friedrich W. H. Kossebau:
> 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?

Am Montag, 13. Mai 2013, 17:41:58 schrieb Friedrich W. H. Kossebau:
> Hi Thiago,
> 
> Am Sonntag, 12. Mai 2013, 14:21:10 schrieb Thiago Macieira:
> > On domingo, 12 de maio de 2013 22.47.35, Friedrich W. H. Kossebau wrote:
> > > +       # Do not export QtUiTools internal symbols
> > > +       set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS
> > > "-Wl,-- exclude-libs -Wl,libQtUiTools.a")
> > 
> > It seems the correct fix would be to compile libQtUiTools.a with -
> > fvisibility=hidden in Qt. It's already the case in Qt 5, so it should not
> > be a problem anymore.
> > 
> > For Qt 4, I could investigate, but does it help if it only applies to Qt
> > 4.8.5 or 4.8.6?
> 
> Depends if one could assume that some people out there are relying on these
> symbols being public. Who can know? Seems so far noone was really bitten by
> it (or at least has found out, like we now have for our KDE software,
> though then this problem should be with us since years potentially, no?),
> so perhaps better to keep things as they are.
> 
> If asked I would simply add a warning somewhere that this lib exposes all
> symbols as is. But not change the ABI, given that there is still the other
> solution for users of the lib, hiding that lib's symbols oneself with the
> "exclude-libs" flag.
> 
> Interesting problem still: so any public symbol from a static lib can
> potentially appear multiple times in a process, if coming with different
> libs/modules, and then the first instance of that symbol shadows all other
> instances, possibly even of incompatible versions? Evil trap...
> 
> So, our problem: Qt 4.8.5 is not out yet. KDE SC 4.10.4 might be out before,
> so ideally the fix goes out with that, to get it to users as soon as
> possible.
> 
> Question now is how to fix this in our code. Is "exclude-libs" supported
> outside gnu ld and gold? And for all platforms?
> 
> What other options are there, for platforms where visibility is not
> supported in any way? Can symbols from static libs be prefixed somehow on
> linking, to avoid clashes?

So how would you fix this in the builds for Windows? Is this an issue there at 
all, or are any symbols from static libs not public anyway, so no mixup is 
happening between the same static lib as part of different modules/libs?

Cheers
Friedrich