[Development] Symbol clashes with static Qt libraries

Tor Arne Vestbø Tor.arne.Vestbo at qt.io
Wed Aug 1 15:48:40 CEST 2018



> On 1 Aug 2018, at 15:45, Kai Koehne <Kai.Koehne at qt.io> wrote:
> 
> Alright, so it seems we have to prefix the symbols we can't hide by static or anonymous namespaces ...
> 
> For logging categories, I'd like to start using 'qlc' as prefix. See also change https://codereview.qt-project.org/#/c/235631/ for qtbase.

Namespaces doesn’t work for that?

> Ossi pointed out in the review that, because it is a private symbol, the 'qt_' prefix would be more correct. Anyhow, that just gets too long ... So I'm asking whether anybody objects making an exception for logging categories.

Agreed, qt_ gets unwieldy, qlc is fine. (Assuming we can’t use a namespace instead)

Tor Arne 

> 
> Regards
> 
> Kai
> 
>> -----Original Message-----
>> From: Development <development-bounces+kai.koehne=qt.io at qt-project.org>
>> On Behalf Of Thiago Macieira
>> Sent: Tuesday, July 31, 2018 4:58 PM
>> To: development at qt-project.org
>> Subject: Re: [Development] Symbol clashes with static Qt libraries
>> 
>> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
>>> 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.
>> 
>> We will not be able to get (c) working everywhere. I remember trying objcopy
>> some years ago messing with symbol properties and I know I wasn't successful.
>> I don't remember what I was trying, though, so this is not a showstopper for
>> our current problem. Just don't get your hopes up.
>> 
>> I think we need (a) and we can apply (c) if possible.
>> 
>>> 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.
>> 
>> Why can't the test run on .a files?
>> 
>>> It however does not protect us from the issue on Windows and macOS,
>>> but it covers the cross-platform code.
>> 
>> nm exists on both too. We won't get it on MSVC, though.
>> 
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>  Software Architect - Intel Open Source Technology Center
>> 
>> 
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list