On Fri, Aug 03, 2018 at 08:27:50AM +0200, Olivier Goffart wrote:
> > The problem we had with a namespaced Qt were: using external Qt
> > based libraries, which never tried to use a namespaced build, did
> > not build due to forward declarations, so I had to patch some of
> > them. But then, not
On Thursday, 2 August 2018 23:03:06 PDT Martin Koller wrote:
> QT_FORWARD_DECLARE_CLASS(QTimer)
Easier to just put QT_BEGIN_NAMESPACE before and QT_END_NAMESPACE after. It's
more verbose, but it's actually easier to read.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:
> Hi,
>
>
> Before concluding that a namespaced Qt is a terrible idea, I recommend trying
> out the feature.
>
>
> It is intended to work transparently and not require any changes to the
> application, nothing like having to
:45 PM
To: development@qt-project.org
Subject: Re: [Development] Symbol clashes with static Qt libraries
Am 31.07.2018 um 14:58 schrieb Edward Welbourne:
> Giuseppe D'Angelo (31 July 2018 14:38)
>> It will likely break every single application that has never used a
>> namespaced bui
Am 31.07.2018 um 14:58 schrieb Edward Welbourne:
Giuseppe D'Angelo (31 July 2018 14:38)
It will likely break every single application that has never used a
namespaced build of Qt. Which is a significant percentage of all the Qt
apps out there...
I'm guessing you mean "... used a static
On Tuesday, 31 July 2018 07:52:37 PDT Thiago Macieira wrote:
> 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.
Done almost all for qtbase, from Kai's listing:
On Wednesday, 1 August 2018 06:48:40 PDT Tor Arne Vestbø wrote:
> > On 1 Aug 2018, at 15:45, Kai Koehne 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.
gt;> To: development@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 w
day, July 31, 2018 4:58 PM
> To: development@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
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
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
> On 31 Jul 2018, at 15:58, Konstantin Shegunov wrote:
>
> On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some
On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user
> code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g. https://codereview.qt-project.
>
On 31/07/18 14:58, Edward Welbourne wrote:
I can believe static-built apps are common; and I guess apps using them
would need to make source changes in order to switch to their namespaced
form, or override the default of them being namespaced. What other
problem(s) had you in mind ?
Exactly
Kai Koehne (Tuesday, 31 July 2018 1:44 PM)
>>> 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?
On 31/07/18 14:06, Mitch
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
On 31/07/18 14:06, Mitch Curtis wrote:
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?
It will likely break every single application that
> -Original Message-
> From: Development project.org> On Behalf Of Kai Koehne
> Sent: Tuesday, 31 July 2018 1:44 PM
> To: development@qt-project.org
> Subject: [Development] Symbol clashes with static Qt libraries
>
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt
> On 31 Jul 2018, at 13:43, Kai Koehne wrote:
>
> 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
>
19 matches
Mail list logo
