Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On terça-feira, 7 de maio de 2013 08.25.48, Koehne Kai wrote: > > -Original Message- > > From: development-bounces+kai.koehne=digia@qt-project.org > > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > > Behalf Of Alan Alpert > > Sent: Wednesday, April 24, 2013 8:30 AM > > To: Thiago Macieira > > Cc: development > > Subject: Re: [Development] 6 conflicting symbols between QtQuick 1 and 2 > > > > [...] > > I agree. I'm just waiting for someone to push the patch to codereview. > > Since apparently nobody has picked the ball up, I uploaded > > https://codereview.qt-project.org/#change,55521,patchset=5 > > for review, which implements Olivier's suggestion (as far as I understood > it). > > Anyhow, would be good if actually someone tests that it resolves the issue > :) Because QtQml and QtDeclarative still exports the same symbols, even if > apps compiled against this patch shouldn't use the QtQUick1 exports any > more. Thanks Kai for stepping up. I wonder if we should make the same change to QtQml. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
Hello Kai, On Tue, 7 May 2013, Koehne Kai wrote: > Since apparently nobody has picked the ball up, I uploaded > > https://codereview.qt-project.org/#change,55521,patchset=5 > > for review, which implements Olivier's suggestion (as far as I understood it). > > Anyhow, would be good if actually someone tests that it resolves the > issue :) Because QtQml and QtDeclarative still exports the same > symbols, even if apps compiled against this patch shouldn't use the > QtQUick1 exports any more. As one of the reporters of the problem we will do that! And sorry about not having been quicker to produce the patch myself. My spare time only allowed for updating my checkout and a rebuild so far. Roy, my colleague who ran into a crash, will try out your patch and report back. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
> -Original Message- > From: development-bounces+kai.koehne=digia@qt-project.org > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > Behalf Of Alan Alpert > Sent: Wednesday, April 24, 2013 8:30 AM > To: Thiago Macieira > Cc: development > Subject: Re: [Development] 6 conflicting symbols between QtQuick 1 and 2 > > [...] > I agree. I'm just waiting for someone to push the patch to codereview. Since apparently nobody has picked the ball up, I uploaded https://codereview.qt-project.org/#change,55521,patchset=5 for review, which implements Olivier's suggestion (as far as I understood it). Anyhow, would be good if actually someone tests that it resolves the issue :) Because QtQml and QtDeclarative still exports the same symbols, even if apps compiled against this patch shouldn't use the QtQUick1 exports any more. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tue, Apr 23, 2013 at 11:22 PM, Thiago Macieira wrote: > On quarta-feira, 24 de abril de 2013 10.24.18, Chris Adams wrote: >> Anyway, I agree with Lars: the QtQuick1 ones could be renamed. > > The ones declared in public headers cannot be simply removed. That would be > source- and binary-incompatible. If we were to take that route, we should > rename the ones in QtQml, so that QtQuick1 retains compatibility with Qt 4. Qt 5.0 has been released and also needs compatibility. So it's just as valid to rename the ones in QtQuick1 so that QtQml retains compatibility with Qt 5. > > No, we should just do what Olivier suggested. It solves the problem more > neatly. I agree. I'm just waiting for someone to push the patch to codereview. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On quarta-feira, 24 de abril de 2013 10.24.18, Chris Adams wrote: > Anyway, I agree with Lars: the QtQuick1 ones could be renamed. The ones declared in public headers cannot be simply removed. That would be source- and binary-incompatible. If we were to take that route, we should rename the ones in QtQml, so that QtQuick1 retains compatibility with Qt 4. No, we should just do what Olivier suggested. It solves the problem more neatly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
qmlEngine() and qmlContext() are documented via qdoc comments in qqmlengine.cpp and should show up in the related functions section of the generated documentation. As you've noticed, however, for some reason the documentation does not show up in the generated documentation. I don't know why. Perhaps Jerome knows. qmlInfo() should be documented also - if it isn't, we need to fix that. Anyway, I agree with Lars: the QtQuick1 ones could be renamed. I really don't think people should be using QtQuick1 and QtQuick2 in the same application, at all, but I guess that's a bit beside the point. This is definitely something we overlooked when doing the QtQuick1-in-Qt5 stuff. Cheers, Chris. On Wed, Apr 24, 2013 at 1:48 AM, Thiago Macieira wrote: > On terça-feira, 23 de abril de 2013 13.04.22, Harri Porten wrote: > > I have not checked the respective use cases of the functions but I guess > > that they are internal to Qt despite being exported? Anyone sees a > problem > > with renaming the functions of v1 or v2 to make their names unique? If > > not, we'll prepare a patch and present it. > > All of those functions are declared in public headers. > > qmlAttachedPropertiesObject is documented in QtQml: > > http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlAttachedPropertiesObject > and it's used in QtQuick1 documentation: > http://qt-project.org/doc/qt-4.8/qml-extending.html#attached-properties > (the documentation for QtQuick1 5.0 is not online) > > qmlContext and qmlEngine are not documented but they are used in QtQml > documentation: > > http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2 > > Also add to your list: > qmlRegisterTypeNotAvailable (it's AUTOTEST_EXPORT in QtQuick1) > > To make matters worse, the following *documented* functions are duplicated: > qmlRegisterRevision > qmlRegisterInterface > qmlRegisterType > qmlRegisterUncreatableType > > And the following are also duplicated, but not documented: > qmlRegisterCustomType > qmlRegisterExtendedType > > They are inline and non-exported, so the impact is minimised. On all modern > platforms, the use of those functions inside one Qt library will not affect > other libraries, even though it's a violation of the C++ standard. > > However, it does make it impossible to use both QtQuick1 and QtQml inside > the > same library or application, or to use two third-party or user libraries, > one > for each QML iteration. The only way to use both QML1 and QML2 in one > application or library is to use a plugin and make the decision > application- > wide (you can't load the two plugins at the same time). > > I'm going to wait for other people to suggest solutions to this. Mine, for > the > moment, is a hammer... > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tuesday, April 23, 2013 12:27:17 Thiago Macieira wrote: > It's highly unlikely that anyone will #include both modules in the same > translation unit. In the future, we're going to laugh at this :). -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On terça-feira, 23 de abril de 2013 19.47.25, Olivier Goffart wrote: > On Tuesday 23 April 2013 08:48:41 Thiago Macieira wrote: > > I'm going to wait for other people to suggest solutions to this. Mine, for > > the moment, is a hammer... > > My suggested solution: > > In the header: > Put those functions in an inline namespace. (Or a normal namespace followed > by an using declaration). Thank you! That's why I wanted someone to provide a solution. Yours is definitely much simpler and helpful than what I had in mind. > In one translation unit, keep an exported version of the old symbols which > calls the new symbol in the namespace, to keep binary compatibility. Right, that falls under the "de-inlining a function" category of binary compatibility. We keep the source compatibility by using an inline namespace. It's highly unlikely that anyone will #include both modules in the same translation unit. > That way, the problem is solved if the application is compiled against Qt > 5.1 or later. > If the application or one linked library is compiled against QtQml or > QtDeclarative from 5.0, and that this library uses one of the problematic > symbol, the crash can still happen. So one must still not link both QtQml, > QtDeclarative, and an old library together. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tuesday 23 April 2013 08:48:41 Thiago Macieira wrote: > I'm going to wait for other people to suggest solutions to this. Mine, for > the moment, is a hammer... My suggested solution: In the header: Put those functions in an inline namespace. (Or a normal namespace followed by an using declaration). In one translation unit, keep an exported version of the old symbols which calls the new symbol in the namespace, to keep binary compatibility. That way, the problem is solved if the application is compiled against Qt 5.1 or later. If the application or one linked library is compiled against QtQml or QtDeclarative from 5.0, and that this library uses one of the problematic symbol, the crash can still happen. So one must still not link both QtQml, QtDeclarative, and an old library together. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On terça-feira, 23 de abril de 2013 13.04.22, Harri Porten wrote: > I have not checked the respective use cases of the functions but I guess > that they are internal to Qt despite being exported? Anyone sees a problem > with renaming the functions of v1 or v2 to make their names unique? If > not, we'll prepare a patch and present it. All of those functions are declared in public headers. qmlAttachedPropertiesObject is documented in QtQml: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlAttachedPropertiesObject and it's used in QtQuick1 documentation: http://qt-project.org/doc/qt-4.8/qml-extending.html#attached-properties (the documentation for QtQuick1 5.0 is not online) qmlContext and qmlEngine are not documented but they are used in QtQml documentation: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2 Also add to your list: qmlRegisterTypeNotAvailable (it's AUTOTEST_EXPORT in QtQuick1) To make matters worse, the following *documented* functions are duplicated: qmlRegisterRevision qmlRegisterInterface qmlRegisterType qmlRegisterUncreatableType And the following are also duplicated, but not documented: qmlRegisterCustomType qmlRegisterExtendedType They are inline and non-exported, so the impact is minimised. On all modern platforms, the use of those functions inside one Qt library will not affect other libraries, even though it's a violation of the C++ standard. However, it does make it impossible to use both QtQuick1 and QtQml inside the same library or application, or to use two third-party or user libraries, one for each QML iteration. The only way to use both QML1 and QML2 in one application or library is to use a plugin and make the decision application- wide (you can't load the two plugins at the same time). I'm going to wait for other people to suggest solutions to this. Mine, for the moment, is a hammer... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
Hi Harri, having the symbols clash is not a good idea in any case, so please go ahead and rename one set. I'd go for changing the ones in Qt Quick 1. Cheers, Lars On 4/23/13 1:04 PM, "Harri Porten" wrote: >Hi! > >Don't ask why but we ran into the known[1] segfault caused by symbol name >conflicts between Qt5Qml and Qt5Declarative. Checking the symbol tables >it >appears to because by 6 symbols only: > > qmlContext(QObject const*) > qmlExecuteDeferred(QObject*) > qmlAttachedPropertiesObject(int*, QObject const*, QMetaObject const*, >bool) > qmlAttachedPropertiesObjectById(int, QObject const*, bool) > qmlInfo(QObject const*) > qmlEngine(QObject const*) > >At least for non-VS compilers the partially different return types (QQml* >vs. QDeclarative*) don't help with having a different symbol name >mangling. At the same time the functions cannot be used interchangeably >either. So I assume that this conflict was a simply copy&paste oversight >during the porting. > >I have not checked the respective use cases of the functions but I guess >that they are internal to Qt despite being exported? Anyone sees a >problem >with renaming the functions of v1 or v2 to make their names unique? If >not, we'll prepare a patch and present it. > >To stress one point: we are not attempting to run both types of GUIs in a >single application. We'd just like to have the possibility to have the >two >libraries co-exist and optionially be used. > >Harri. > >[1] https://bugreports.qt-project.org/browse/QTBUG-29584 > > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
