Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)

[Thiago Macieira]

On segunda-feira, 13 de maio de 2013 19.05.54, Friedrich W. H. Kossebau wrote:
> Am Montag, 13. Mai 2013, 10:06:59 schrieb Thiago Macieira:
> > On segunda-feira, 13 de maio de 2013 17.41.58, Friedrich W. H. Kossebau
> 
> wrote:
> > > 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...
> > 
> > This is the same old problem of conflicting symbols. It's nothing new.
> > 
> > In fact, it still exists *because* it's missing the latest innovation,
> > from
> > 2005: hidden symbols.
> 
> Never hit this problem with _static_ libs in all the years so far, so new
> for me ;)

Because most sane people link the static library to the final executable. There 
are very few crazy people that link a static library to a dynamic library.

THAT is the issue.

> ((I somehow would have assumed that symbols from static libs are namespaced
> on linking, especially as noone seems to have guarded such linking in any
> other way, also did not catch my attention elsewhere yet. 

There's no namespacing. You may have assumed that they were hidden. And when 
this thread came about, I didn't know the answer without checking.

And indeed, it seems that we changed from 4.8 to 5.0 without giving it a 
second thought. In all his refactorings, Ossi or I probably caused this change 
unintentionally. But it's now for the better.

> Possibly because
> people were not aware that libQtUiTools is a static and not a shared lib,
> this fact being hidden behind the var ${QT_QTUITOOLS_LIBRARY}))

Probably the case.

> So, still wondering what the (most) platform-independent fix can be from our
> side to this problem?

Platform-independent? There isn't once, since hidden visibility is also 
platform-dependent.

For now, I'd say use the SUSE solution and be done with it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130513/2f1ea6f1/attachment.sig>