[Development] Symbol clashes with static Qt libraries

[Simon Hausmann]

Hi,


I recall that when we first discovered this issue - many many years ago - we introduced the tst_symbols auto-test (with Harald). Today it lives in the qtqa repo and it's run for every module. It serves the purpose of verifying that we don't have unprefixed exported symbols. Since this is hard to get right, the test itself has a fair amount of heuristics in place, but I think in principle it gets it right.


At the time when we introduced the test, ELF visibility was not a thing yet on Linux (where this test is limited to). That's why it worked. When we started using ELF visibility, things go easier for our users on Linux, but the test stopped protecting us from the issue that remains in static builds.


I favor (a) along with the existing test, because of the issues Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for us.


If we wanted to make this test work again (and produce errors with your logging category examples), then we would need a configuration in the CI that builds on Linux without ELF visibility. At least that's one of the ways it could be done with minimal effort.


It however does not protect us from the issue on Windows and macOS, but it covers the cross-platform code.


It's not perfect, but I think we can improve the situation that we've been living with for many years considerably with minimal effort.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Kai Koehne <Kai.Koehne at qt.io>
Sent: Tuesday, July 31, 2018 1:43:36 PM
To: development at qt-project.org
Subject: [Development] Symbol clashes with static Qt libraries

Hi,

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 Q_DECLARE_LOGGING_CATEGORY).

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 qtbase.

b) Advise people to always configure static Qt in a namespace (-qtnamespace).

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?

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

--
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 B

The Future is Written with Qt
www.qtworldsummit.com<http://www.qtworldsummit.com>

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180731/e5054aae/attachment.html>