> On May 22, 2013, 6:28 p.m., Alexander Neundorf wrote: > > The documentation for the macro should be at the top of > > FindKDE4Internal.cmake, where all the documentation is. > > > > For the technical side: this flag is new to me. Is it the only possible > > solution ? Thiago ? > > Thomas Lübking wrote: > > For the technical side: this flag is new to me. > I wasn't aware it's used and grepping the Makefiles of kdelibs, workspace > and runtime didn't show it here, btw. > > What it does: > http://www.technovelty.org/c/what-exactly-does-bsymblic-do.html > > My 2¢ > There're various issues with it and i dare to claim that you more or less > want to use it alongside --dynamic-list only. > Alternatively one would use > __attribute__((visibility("[hidden|protected]"))) or the "-version-script" > switch to protect/accelerate *certain* funtion/calls. (protected visibility > is afair gcc only, though) > > If "downstream" applies it, i'd frankly tell "downstream" to rtfm and not > just push everything claimed to "make it fasta!!!" > > This is by no means sth. one should apply "uninformed" since it has > impact on the runtime behavior that the developer needs to know about > ("whoops, my trick to shadow friend qt_foo() to gain access to > protected/private d->bar only works sometiems" - yes, one should not hack, > but one should also be aware that this hack can "legally" fail and not wonder > why it works here and on distro X but fails on distro Y) > > Friedrich W. H. Kossebau wrote: > Now the KDE packages for OpenSUSE are said to have been created with that > flag already for a while, given Hrvoje Senjan saying "we are using it 4 years > already, this is first known issue it's caused so far" > (https://bugzilla.novell.com/show_bug.cgi?id=819437#c14) > > http://qt-project.org/wiki/Performance_Tip_Startup_Time says: "Use > -Bsymbolic-functions for your shared libraries.", more or less, with no big > warnings. (Please note your warnings there, to have more downstream rtfm :) ) > > Surely -Bsymbolic-functions should be used with care. > > > Still, we have the problem that QtUitools.a exposes all its symbols on > Linux & similar. Which means symbol clashes if loaded multiple times in the > same process. With and without -Bsymbolic-functions. One could fix > QtUitools.a for 4.8.future. Or see to do on our side what can be done, i.e. > explicitely hide those symbols when linking the now existing versions of the > static lib QtUitools.a into our code, so any of our code does not even try to > lookup its symbols in the wrong place. > > Which is what the proposed patch does, offer the option to mark an extern > static library to be linked without exposing its symbols, on those platform > where it is needed. > > What other solution would there be?
It does usually rather not cause the kind of issue where you'd say "oh, yes - that's because of the linker behavior" and the better solution was to upstream version tag symbols - so one gets consistent behavior and also has more fine grained control over protection/acceleration. This general consideration aside, in the particular incident Thiago already pointed that QtUitools hides symbols in Qt5 (in the mailing ist, iirc) so it's certainly the proper solution until then - i didn't mean to question that aspect. The only problem would be the limited presence of that linker option (seems GNU ld only and also on certain architectures) - still better than nothing, until and if the next Qt version would backport hiding the symbols as Thiago also ... implied ... ;-) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110563/#review32984 ----------------------------------------------------------- On May 22, 2013, 6:45 p.m., Friedrich W. H. Kossebau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110563/ > ----------------------------------------------------------- > > (Updated May 22, 2013, 6:45 p.m.) > > > Review request for Build System, kdelibs, Alexander Neundorf, and Thiago > Macieira. > > > Description > ------- > > Like discussed in the thread "Crashes with libQtUiTools.a if linked multiple > times into the same process (with Bsymbolic-functions flag)" on > kde-core-devel ( http://lists.kde.org/?t=136829863100001&r=1&w=2 ) symbols > from QtUitools.a are not hidden by default in Qt4 and thus will be added to > the public symbols of the module/shared lib they are linked to. And thus can > appear multiple times in the same process, resulting in symbol clashes and > leading to problems at least with the Bsymbolic-functions flag or when being > possibly incompatible versions. > > Attached patch sees to solve that problem, by adding a macro > KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS which should add any needed linker flags > depending on the platform/linker used. > > Only issue is that instead of some variable I had to use "QtUiTools.a" as I > found no variable which would resolve to that. E.g. ${QT_QTUITOOLS_LIBRARY} > resolves to "Qt4::QtUiTools" for me. Any idea what to use there, in case > another platform needs another name/prefix here? > > Patch is against 4.10 branch, so I hope to get this in 4.10.4 > > http://lxr.kde.org/search?v=4.10-branch&filestring=&string=QT_QTUITOOLS_LIBRARY > shows that there are some more places where the symbols need hiding, but I > first want feedback on the proposed approach. > > > Diffs > ----- > > cmake/modules/FindKDE4Internal.cmake cb63285 > cmake/modules/KDE4Macros.cmake 3db4e24 > kjsembed/kjsembed/CMakeLists.txt d70f260 > kross/modules/CMakeLists.txt d245fd8 > kross/qts/CMakeLists.txt d8cb4a5 > plasma/CMakeLists.txt 674550d > > Diff: http://git.reviewboard.kde.org/r/110563/diff/ > > > Testing > ------- > > > Thanks, > > Friedrich W. H. Kossebau > >
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
