Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)
Friedrich W. H. Kossebau
kossebau at kde.org
Mon May 13 16:41:58 BST 2013
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
More information about the kde-core-devel
mailing list