Review Request 110563: Crash fix: hide symbols from static lib QtUitools.a (generically by new macro KDE4_HIDE_SYMBOLS_FROM_STATIC_LIBS)

[Thomas Lübking]

> 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 ?

> 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)


- 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20130522/0a295ddf/attachment-0001.html>