[Development] Symbol clashes with static Qt libraries
mitch.curtis at qt.io
Tue Jul 31 14:06:38 CEST 2018
> -----Original Message-----
> From: Development <development-bounces+mitch.curtis=qt.io at qt-
> project.org> On Behalf Of Kai Koehne
> Sent: Tuesday, 31 July 2018 1:44 PM
> To: development at qt-project.org
> Subject: [Development] Symbol clashes with static Qt libraries
> I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
> Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG-
> 67692 : We have the convention to name logging categories (which are
> actually functions) with 'lc', such as 'lcCanvas'. Since logging categories
> shouldn't be exported, this is fine for dynamic libs. However, for static builds
> of Qt, the symbol might clash with symbols of the same name from other
> libraries / user code, potentially resulting in linker errors.
> (And no, we can't mark the logging category objects as static / in an
> anonymous namespace because they can be pre-declared by
> Note also that the logging categories are by far not the only non-prefixed
> symbols that might cause clashes when statically linking. See
> https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that
> don't contain a q or Q , for a static Qt build of mine.
> I can think of 3 approaches to tackle this:
> a) Prefix all symbols with 'q', like we do for exported symbols.
> This requires some bigger patches. See e.g. https://codereview.qt-
> project.org/#/c/235631/ for renaming all logging categories to 'qlc*' in
> b) Advise people to always configure static Qt in a namespace (-
> This should fix it for symbols at least in our own code. Maybe we should
> make it even the default for static builds in Qt 6?
This one is a nice compromise, in that it's just an extra argument to pass to configure. Though, like you said, the issue is making people aware of it.
Are there any downsides to doing this by default?
> c) Look into tricks like 'objcopy --localize-hidden' to hide symbols.
> This would probably require some major hackery in the build system. No idea
> whether this is supported also on other platforms, and how hard it would be
> to pull it off. I'm not volunteering 😉
> I guess I'm not the first one who looks into this, so I'm happy to hear
> advice/opinions 😊
> Kai Koehne, Senior Manager R&D | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331
> The Future is Written with Qt
> Development mailing list
> Development at qt-project.org
More information about the Development