Description of problem: I was trying to build bibletime in koji, but the build is failing at configure time with the following message; >> ... checking for Qt... libraries /usr/lib/qt-3.3/lib, headers /usr/lib/qt-3.3/include using -mt checking for moc... /usr/lib/qt-3.3/bin/moc checking for uic... /usr/lib/qt-3.3/bin/uic checking whether uic supports -L ... yes checking whether uic supports -nounload ... yes checking if Qt needs -ljpeg... no checking for rpath... no checking for KDE... libraries /usr/lib, headers /usr/include/kde checking if UIC has KDE plugins available... no configure: error: you need to install kdelibs first. If you did install kdelibs, then the Qt version that is picked up by this configure is not the same version you used to compile kdelibs. The Qt Plugin installed by kdelibs is *ONLY* loadable if its the same Qt version, compiled with the same compiler and the same Qt configuration settings. << I do have kdelib3-devel in the among the BRs, and all the necessary packages were shown to be installed in the root log. I've also noticed that there is truly a new build of qt after the last build of kdelibs3. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: http://koji.fedoraproject.org/koji/taskinfo?taskID=433911
kdelibs3 has been rebuilt very recently. The problem is something else.
Package builds fine for me locally (mock/dist-f9), trying a scratch build now: http://koji.fedoraproject.org/koji/taskinfo?taskID=433954 wierd, failed the same way as you. ??
kdelibs3-3.5.9-2.fc9 was built against qt-3.3.8b-3.fc9, current is qt-3.3.8b-4.fc9, which is a rebuild against GCC 4.3. If the Qt plugin loader encodes the compiler version somewhere, that could be it.
QT_BUILD_KEY used in qt-3.3.8b-3.fc9.i386.rpm built against GCC 4.1: buildkey=i686 Linux g++-4.* full-config QT_BUILD_KEY used in qt-3.3.8b-4.fc9.i386.rpm built against GCC 4.3: buildkey=i686 Linux g++-3.* full-config This is a Qt bug, please fix ASAP before many plugins start picking up the incorrect build key. (All Qt/KDE 3 packages built after qt-3.3.8b-4.fc9.i386.rpm which contain at least one plugin will need a rebuild once this is fixed.)
Well, we *know* qt-3.3.8b-4.fc9.i386.rpm is busted, I'll untag it to avoid poisoning any (more) builds.
Thanks. Looking at the builds which happened in that timeframe, there are apparently no non-scratch builds affected. Deji: bibletime should rebuild fine once Koji has built the repo without the busted qt. I've set this to urgent: Than, we really need this fixed ASAP, if the scripted rebuilds start and this Qt is included, that will be a big mess! qt4 also has to be checked for this issue.
Thank you Kelvin and Rex for looking at this. I wonder if this doesn't mean all qt(3) dependent packages that have been rebuilt for gcc4.3 would need to be rebuilt again after this issue is resolved. Before this buildkey issue, I was having problem with bibletime builds failing (on one arch or the other) sporadically in koji last week without any visible cause. For instance see http://koji.fedoraproject.org/koji/taskinfo?taskID=425736
> I wonder if this doesn't mean all qt(3) dependent packages that have been > rebuilt for gcc4.3 would need to be rebuilt again after this issue is > resolved. No, only the packages built against qt-3.3.8b-4.fc9 are bad. There don't appear to be any, looking at the list of Koji builds. > http://koji.fedoraproject.org/koji/taskinfo?taskID=425736 That's probably a GCC 4.3 incompatibility in bibletime, the errors are well-hidden due to parallel make (it tends to drown errors in successful output from builds running in parallel): In file included from cmanageindiceswidget.moc.cpp:11: cmanageindiceswidget.h: At global scope: cmanageindiceswidget.h:29: error: expected class-name before '{' token cmanageindiceswidget.moc.cpp: In static member function 'static QMetaObject* BookshelfManager::CManageIndicesWidget::staticMetaObject()': cmanageindiceswidget.moc.cpp:54: error: 'ManageIndicesForm' has not been declared cmanageindiceswidget.moc.cpp: In member function 'virtual void* BookshelfManager::CManageIndicesWidget::qt_cast(const char*)': cmanageindiceswidget.moc.cpp:78: error: 'ManageIndicesForm' has not been declared cmanageindiceswidget.moc.cpp: In member function 'virtual bool BookshelfManager::CManageIndicesWidget::qt_invoke(int, QUObject*)': cmanageindiceswidget.moc.cpp:87: error: 'ManageIndicesForm' has not been declared cmanageindiceswidget.moc.cpp: In member function 'virtual bool BookshelfManager::CManageIndicesWidget::qt_emit(int, QUObject*)': cmanageindiceswidget.moc.cpp:94: error: 'ManageIndicesForm' has not been declared cmanageindiceswidget.moc.cpp: In member function 'virtual bool BookshelfManager::CManageIndicesWidget::qt_property(int, int, QVariant*)': cmanageindiceswidget.moc.cpp:100: error: 'ManageIndicesForm' has not been declared (The second bunch of errors is probably caused by the first, the first is most likely due to cmanageindiceswidget.h not including all headers it needs.)
This bug is due to this snippet in Qt 3's configure: #------------------------------------------------------------------------------- # generate QT_BUILD_KEY #------------------------------------------------------------------------------- # some compilers generate binary incompatible code between different versions, # so we need to generate a build key that is different between these compilers case "$COMPILER" in g++*) # GNU C++ QMAKE_CONF_COMPILER=`grep "QMAKE_CXX[^_A-Z0-9a-z]" $QMAKESPEC/qmake.conf | sed "s,.* *= *\(.*\)$,\1,"` COMPILER_VERSION=`${QMAKE_CONF_COMPILER} --version 2>/dev/null` case "$COMPILER_VERSION" in *2.95.*) COMPILER_VERSION="2.95.*" ;; *3.*) COMPILER_VERSION="3.*" ;; *4.*) COMPILER_VERSION="4" ;; *) ;; esac [ ! -z "$COMPILER_VERSION" ] && COMPILER="g++-${COMPILER_VERSION}" ;; *) # ;; esac See what's wrong already? No? Look closer: 4.3.0 matches *3.*! So it sees this as a 3.x and won't even look for 4.x anymore. In Qt 4, this has been fixed to: #------------------------------------------------------------------------------- # generate QT_BUILD_KEY #------------------------------------------------------------------------------- # some compilers generate binary incompatible code between different versions, # so we need to generate a build key that is different between these compilers case "$COMPILER" in g++*) # GNU C++ QMAKE_CONF_COMPILER=`getQMakeConf | grep "^QMAKE_CXX[^_A-Z0-9]" | sed "s,.* *= *\(.*\)$,\1,"` COMPILER_VERSION=`${QMAKE_CONF_COMPILER} --version 2>/dev/null | sed 's,^[^0-9]*,,g'` case "$COMPILER_VERSION" in 2.95.*) COMPILER_VERSION="2.95.*" ;; 3.*) COMPILER_VERSION="3.*" ;; 4.*) COMPILER_VERSION="4" ;; *) ;; esac [ '!' -z "$COMPILER_VERSION" ] && COMPILER="g++-${COMPILER_VERSION}" ;; *) # ;; esac Than, please fix the qt configure to remove the bogus asterisks. (Or I could do it if you give me commit access to qt.)
Created attachment 295124 [details] qt-x11-free-3.3.8b-gcc4-buildkey.patch The attached patch replaces qt-x11-free-3.3.5-gcc4-buildkey.patch. It incorporates both the "4"->"4.*" change from qt-x11-free-3.3.5-gcc4-buildkey.patch and the fixed version detection backported from Qt 4.
Thanks for giving me commit access, I'll commit and build the fix as soon as the ACLs are synced.
Committed, can't build due to Koji bustage: http://koji.fedoraproject.org/koji/taskinfo?taskID=434898 exceptions.IOError: [Errno 5] Input/output error https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01561.html
*** Bug 433264 has been marked as a duplicate of this bug. ***
My fix was now successfully built for Rawhide by Than.