Version: (using Devel) Compiler: gcc 4.3.2 OS: Linux Installed from: Compiled sources Trying to build smoke with a current Qt 4.5 snapshot fails with: /usr/src/ark/BUILD/kdebindings/smoke/qt/x_11.cpp: In member function 'void x_QMetaObjectExtraData::x_2(Smoke::StackItem*)': /usr/src/ark/BUILD/kdebindings/smoke/qt/x_11.cpp:760: error: expected unqualified-id before 'int' /usr/src/ark/BUILD/kdebindings/smoke/qt/x_11.cpp:760: error: expected `;' before 'int' The generated code is: class x_QMetaObjectExtraData : public QMetaObjectExtraData { [...] 758 void x_2(Smoke::Stack x) { 759 // int(* static_metacall)(QMetaObject::Call, int, void**) 760 this->QMetaObjectExtraData::int(*(* static_metacall)(QMetaObject::Call *)x[1].s_voidp,(int)x[2].s_int,(void**)x[3].s_voidp); 761 (void)x; // noop (for compiler warning) 762 }
I got the same message as above when compiling with Qt 4.5 beta 1, plus the following error also: x_3.cpp:4417: error: ‘Qt_4_6’ is not a member of ‘QDataStream’ with the generated code being: static void x_12(Smoke::Stack x) { x[0].s_enum = (long)QDataStream::Qt_4_5; } static void x_13(Smoke::Stack x) { x[0].s_enum = (long)QDataStream::Qt_4_6; } static void x_14(Smoke::Stack x) { x[0].s_enum = (long)QDataStream::BigEndian; }
Actually I ran into that one too, but it is easy to work around. Given Qt_4_6's definition in qdatastream.h is enum Version { [...] #if QT_VERSION >= 0x040600 #error Add the datastream version for this Qt version , Qt_4_6 = Qt_4_5 #endif }; and there's no way QT_VERSION could be >= 0x040600 with Qt 4.5.x (I think there's only 2 ways to actually hit the definition -- the first is being a Qt developer and increasing the version number to 4.6, the second is severely messing up a system by mixing Qt 4.5 and 4.6 headers), simply removing it in qdatastream.h doesn't actually change anything.
I have hit this bug as well with KDE 4.2.0 and Qt 4.5.0 RC1. One of the previous posters indicates that it is easy to get around, but fails to describe a fix or provide a patch. Is the issue with Qt or KDE? Is this corrected in KDE trunk (4.3) assuming it is a KDE issue (what commit corrects)? Or if Qt, can someone describe how to fix or provide a patch?
This was fixed around the time of Qt 4.5.0...