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?

Cheers
Friedrich