Qt 5.4.2 - building whith -no-feature-CURSOR -> QT_NO_CURSOR
-
I got compile error for libQt5Gui:
qsimpledrag.cpp:(.text+0x584): undefined reference to `QCursor::pos()'When I look link command , we got "qcursor" referencese
arm-v5te-linux-gnueabi-g++ -Wl,--no-undefined -Wl,-O1 -Wl,-rpath,/usr/lib/arm-linux-gnu/qt5.4/lib -shared -Wl,-soname,libQt5Gui.so.5 -o libQt5Gui.so.5.4.2 ... .obj/qplatformcursor.o ... .obj/qcursor.o ...but "qcursor.o" his quite empty , must be due to "fake cursor"
Do my problem is link to this note in "qcursor.h" ?
"The fake cursor has to go first with old qdoc."Any explanation of this note ?
-
Hi,
What arguments did you pass to configure ?
-
this i my arguments :
-opensource -confirm-license -release -continue -v -prefix /usr/lib/arm-linux-gnu/qt5.4 -xplatform linux-arm-v5te-gnueabi-g++ -tslib -linuxfb -no-opengl -no-c++11 -no-dbus -no-gtkstyle -no-feature-CURSOR -no-feature-CLIPBOARD -no-feature-WHEELEVENT -no-feature-CUPS -qt-zlib -qt-libjpeg -qt-libpng -make libs -nomake tools -nomake examples -nomake tests -I/home/benoit/Développement/Linux-Embedded/tslib-1.0/src -L/usr/lib/arm-linux-gnu
I move precompil "ifndef" like in Qt 5.5 and libGui succed.
I got other problem for Qml part ..i found some fixes for then.
I keeping solving problem one by one ... (or may be use Qt 5.5.0?) -
There's indeed a ifndef missing. Would you consider submitting a patch for that ?
The current stable is 5.5.1. You also can test 5.6.0 Beta.
What QML problem did you have ?
-
for QLM , i had problem with :
hidden symbol `void QQmlThread::postMethodToThread<QQmlDataBlob*, QQmlDataBlob*, QQmlDataLoaderThread>(void (QQmlDataLoaderThread::)(QQmlDataBlob), QQmlDataBlob* const&)' isn't definedI found a post about modify "qml.pro"
QMAKE_CXXFLAGS_RELEASE += -fno-inlinehttps://wiki.qt.io/Building_Qt_5_from_Git
thanks Samuel for your answers . tomorrow I will try to deal with Qt5.5.0 and Qt5.5.1 (i hope having less errors)
P.S. for "patch" . I don't know branch rules in Qt , but according what we do at work for our software. if the last (production/stable/recommended) is fixed for a "bug" no need to patch (beta/experimental) old one ? "use the last version" (here 5.5.1)
-
For fixes it should go to the current released minor branch e.g. 5.5 (or currently 5.6 since it's almost out and it's unlikely that a 5.5.2 will be released). For new features it's the dev branch. Note that depending on the fix, if it has far reaching implications then targeting dev is better. In any case, a patch against the wrong branch can be moved (it happens if e.g. a submission wasn't validated before a new minor release)
