[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-funct
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2013-05-12 20:47:35
Message-ID: 13825743.svVK4fJ5Y9 () klux ! site
[Download RAW message or body]

Hi Sune,

Am Samstag, 11. Mai 2013, 20:23:15 schrieb Sune Vuorela:
> On 2013-05-11, Friedrich W. H. Kossebau <kossebau@kde.org> wrote:
> > So, anyone with more clue than me WRT symbols from static libs and the
> > Bsymbolic-functions linker flag who could tell if that indeed should fix
> > such problems if code from the same static lib is arriving multiple times
> > in the same process via different libs/modules?
> 
> It most likely will help on such a case.
> 
> -Bsymbolic-functions ensures that functiotns are first resolved in the
> library/plugin itself before resolving it from outside the library.
> 
> What happens, I think, is that it is sometimes using the functions from
> one of the static libs, other times from some of the other.
> 
> I'm not sure we want libraries linking QtTools to be built with
> -Bsymbolic-functions because it breaks debugging and other magic using
> function overriding with LD_PRELOAD tricks, because they rely on being
> chosen first over the 'internal' functions.

Bsymbolic-functions seems default for all qt/kde libs these days, no? So it 
would need to be removed everywhere if following your answers.

In the meantime downstream (openSUSE KDE maintainers) have created a different 
patch which instead simply tells the linker to exclude libQtUiTools.a when 
generating the public symbols, by calling in all relevant places
+	# Do not export QtUiTools internal symbols
+	set_target_properties(krossmoduleforms PROPERTIES LINK_FLAGS "-Wl,--
exclude-libs -Wl,libQtUiTools.a")

See request
https://build.opensuse.org/package/view_file?file=exclude-qtuitools-symbols-from-public-libraries.patch&package=kdelibs4&project=KDE%3ADistro%3AFactory


Hopefully that will soon make it upstream if it proves to be "the right fix" 
(tm).

Cheers
Friedrich


[prev in list] [next in list] [prev in thread] [next in thread]