[Development] Symbol clashes with static Qt libraries

[Thiago Macieira]

On Tuesday, 31 July 2018 04:43:36 PDT Kai Koehne wrote:
> 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.

Well, it could be much worse.  There are a couple of low-hanging fruits there 
that we can easily fix. I'll take a look later today on those applying to 
QtCore.

Your list also includes third-party libraries (doubleconversion, Harfbuzz, 
xkb). Can you check whether those symbols come from a Qt library or from that 
particular library that was linked into your application? That is, were the 
sources from that library added to the Qt's .a file? Or was there a .a for 
that library?

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

Ugly, but good idea. Another trick, which is not a one-line patch, is:

namespace QtLogging {
Q_CATEGORY_LOGGING(whatever)
}
using QtLogging::whatever;

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

Recommendation, but it's not too bad today anyway. People have been using 
static builds for over two decades. So a recommendation I agree with.

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

That I don't.

> 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 

We don't need it in all platforms, but this post-processing step isn't a bad 
idea where it is present. Good idea.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center