<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/110563/">http://git.reviewboard.kde.org/r/110563/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On May 22nd, 2013, 6:28 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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 ?</pre>
 </blockquote>




 <p>On May 22nd, 2013, 7:03 p.m. UTC, <b>Thomas Lübking</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 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)</pre>
 </blockquote>





 <p>On May 27th, 2013, 11:36 p.m. UTC, <b>Friedrich W. H. Kossebau</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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 ... ;-)</pre>
<br />










<p>- Thomas</p>


<br />
<p>On May 22nd, 2013, 6:45 p.m. UTC, Friedrich W. H. Kossebau wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Build System, kdelibs, Alexander Neundorf, and Thiago Macieira.</div>
<div>By Friedrich W. H. Kossebau.</div>


<p style="color: grey;"><i>Updated May 22, 2013, 6:45 p.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
  </td>
 </tr>
</table>





<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>cmake/modules/FindKDE4Internal.cmake <span style="color: grey">(cb63285)</span></li>

 <li>cmake/modules/KDE4Macros.cmake <span style="color: grey">(3db4e24)</span></li>

 <li>kjsembed/kjsembed/CMakeLists.txt <span style="color: grey">(d70f260)</span></li>

 <li>kross/modules/CMakeLists.txt <span style="color: grey">(d245fd8)</span></li>

 <li>kross/qts/CMakeLists.txt <span style="color: grey">(d8cb4a5)</span></li>

 <li>plasma/CMakeLists.txt <span style="color: grey">(674550d)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/110563/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>