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
On Tue, Apr 23, 2013 at 11:22 PM, Thiago Macieira thiago.macie...@intel.com 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
[Development] 6 conflicting symbols between QtQuick 1 and 2
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 copypaste 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
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 por...@froglogic.com 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 copypaste 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
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
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 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, 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 stephen.ke...@kdab.com | 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
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 thiago.macie...@intel.comwrote: 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
