<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi,</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">It however does not protect us from the issue on Windows and macOS, but it covers the cross-platform code.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Simon</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Development <development-bounces+simon.hausmann=qt.io@qt-project.org> on behalf of Kai Koehne <Kai.Koehne@qt.io><br>
<b>Sent:</b> Tuesday, July 31, 2018 1:43:36 PM<br>
<b>To:</b> development@qt-project.org<br>
<b>Subject:</b> [Development] Symbol clashes with static Qt libraries</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
I'm wondering how we can avoid symbol clashes in static Qt libs + user code.<br>
<br>
Reason why I'm looking into this is <a href="https://bugreports.qt.io/browse/QTBUG-67692">
https://bugreports.qt.io/browse/QTBUG-67692</a> : 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.<br>
<br>
(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).<br>
<br>
Note also that the logging categories are by far not the only non-prefixed symbols that might cause clashes when statically linking. See
<a href="https://paste.kde.org/poeiwjlw3">https://paste.kde.org/poeiwjlw3</a> for all symbols in qtbase/lib/Qt5*.a that don't contain a q or Q , for a static Qt build of mine.<br>
<br>
I can think of 3 approaches to tackle this:<br>
<br>
a) Prefix all symbols with 'q', like we do for exported symbols.<br>
<br>
This requires some bigger patches. See e.g. <a href="https://codereview.qt-project.org/#/c/235631/">
https://codereview.qt-project.org/#/c/235631/</a> for renaming all logging categories to 'qlc*' in qtbase.<br>
<br>
b) Advise people to always configure static Qt in a namespace (-qtnamespace).<br>
<br>
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?<br>
<br>
c) Look into tricks like 'objcopy --localize-hidden' to hide symbols.<br>
<br>
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 ðŸ˜‰<br>
 <br>
I guess I'm not the first one who looks into this, so I'm happy to hear advice/opinions ðŸ˜Š<br>
<br>
Kai<br>
<br>
--<br>
Kai Koehne, Senior Manager R&D | The Qt Company<br>
<br>
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin<br>
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der<br>
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, <br>
HRB 144331 B<br>
<br>
The Future is Written with Qt<br>
<a href="http://www.qtworldsummit.com">www.qtworldsummit.com</a><br>
<br>
_______________________________________________<br>
Development mailing list<br>
Development@qt-project.org<br>
<a href="http://lists.qt-project.org/mailman/listinfo/development">http://lists.qt-project.org/mailman/listinfo/development</a><br>
</div>
</span></font></div>
</body>
</html>