ctdata.o .obj/release-shared/qhelpcollectionhandler.o .obj/release-shared/qhelpsearchengine.o .obj/release-shared/qhelpsearchquerywidget.o .obj/release-shared/qhelpsearchresultwidget.o .obj/release-shared/qhelpsearchindex_default.o .obj/release-shared/qhelpsearchindexwriter_default.o .obj/release-shared/qhelpsearchindexreader_default.o .obj/release-shared/qhelpsearchindexreader.o .obj/release-shared/qclucenefieldnames.o .obj/release-shared/qhelp_global.o .obj/release-shared/qhelpsearchindexwriter_clucene.o .obj/release-shared/qhelpsearchindexreader_clucene.o .obj/release-shared/moc_qhelpenginecore.o .obj/release-shared/moc_qhelpengine.o .obj/release-shared/moc_qhelpengine_p.o .obj/release-shared/moc_qhelpdbreader_p.o .obj/release-shared/moc_qhelpcontentwidget.o .obj/release-shared/moc_qhelpindexwidget.o .obj/release-shared/moc_qhelpgenerator_p.o .obj/release-shared/moc_qhelpcollectionhandler_p.o .obj/release-shared/moc_qhelpsearchengine.o .obj/release-shared/moc_qhelpsearchquerywidget.o .obj/release-shared/moc_qhelpsearchresultwidget.o .obj/release-shared/moc_qhelpsearchindexwriter_default_p.o .obj/release-shared/moc_qhelpsearchindexreader_default_p.o .obj/release-shared/moc_qhelpsearchindexreader_p.o .obj/release-shared/moc_qhelpsearchindexwriter_clucene_p.o .obj/release-shared/moc_qhelpsearchindexreader_clucene_p.o .obj/release-shared/qrc_helpsystem.o -L/usr/lib64 -L/var/tmp/portage/dev-qt/qthelp-4.8.5-r1/work/qt-everywhere-opensource-src-4.8.5/lib -L/usr/lib64/qt4 -lQtSql -L/usr/lib64 -lQtGui -L/usr/X11R6/lib -lQtNetwork -lQtCore -lgthread-2.0 -lglib-2.0 -lpthread -lQtCLucene .obj/release-shared/qhelpgenerator.o: In function `QHelpGenerator::generate(QHelpDataInterface*, QString const&)': qhelpgenerator.cpp:(.text+0x965a): undefined reference to `QDataStream::QDataStream(QByteArray*, int)' .obj/release-shared/qhelpsearchindexwriter_clucene.o: In function `fulltextsearch::clucene::QHelpSearchIndexWriter::writeIndexMap(QHelpEngineCore&, QMap<QString, QDateTime> const&)': qhelpsearchindexwriter_clucene.cpp:(.text+0x6cf): undefined reference to `QDataStream::QDataStream(QByteArray*, int)' collect2: error: ld returned 1 exit status make: *** [../../../lib/libQtHelp.so.4.8.5] Error 1 * ERROR: dev-qt/qthelp-4.8.5-r1 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=dev-qt/qthelp-4.8.5-r1'`, * the complete build log and the output of `emerge -pqv '=dev-qt/qthelp-4.8.5-r1'`. * The complete build log is located at '/var/tmp/portage/dev-qt/qthelp-4.8.5-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-qt/qthelp-4.8.5-r1/temp/environment'. * Working directory: '/var/tmp/portage/dev-qt/qthelp-4.8.5-r1/work/qt-everywhere-opensource-src-4.8.5/tools/assistant/lib' * S: '/var/tmp/portage/dev-qt/qthelp-4.8.5-r1/work/qt-everywhere-opensource-src-4.8.5' >>> Failed to emerge dev-qt/qthelp-4.8.5-r1, Log file: Reproducible: Always
Created attachment 353674 [details] emerge --info
Created attachment 353676 [details] build log
Same problem on a ~x86 machine
Here are the QT core packages I have: $ qlist -ICc dev-qt dev-qt/qt-creator 2.8.0_rc dev-qt/qtcore 4.8.5 dev-qt/qtdbus 4.8.5 dev-qt/qtdeclarative 4.8.5 dev-qt/qtgui 4.8.5 dev-qt/qthelp 4.8.4 dev-qt/qtopengl 4.8.5 dev-qt/qtscript 4.8.5 dev-qt/qtsql 4.8.5 dev-qt/qtsvg 4.8.5 dev-qt/qtxmlpatterns 4.8.5 dev-qt/qthelp is needed for qt-creator and is the last QT core package to upgrade.
KDE strikes. Adding 'qt3support' to IUSE and '$(qt_use qt3support)' in src_configure seems to fix the problem. The question is whether it needs to be a useflag and if so, will qtcore need [qt3support=]. On that note: would it be possible to pull qt3to4 from qt3support into a separate package ? It doesn't need libQt3Support.
Adding 'qt3support' to IUSE and '$(qt_use qt3support)' in src_configure seems to fix the problem for me too
(In reply to Rafał Mużyło from comment #5) > KDE strikes. > > Adding 'qt3support' to IUSE and '$(qt_use qt3support)' in src_configure > seems to fix the problem. > > The question is whether it needs to be a useflag and if so, will qtcore need > [qt3support=]. Indeed, that needs to be investigated. It sounds weird to me that a qt module hard-requires qt3support, but I cannot exclude it either. > > On that note: would it be possible to pull qt3to4 from qt3support into a > separate package ? It doesn't need libQt3Support. Uhm...why? It's just a very very tiny utility, splitting doesn't seem worth the effort...
(In reply to Davide Pesavento from comment #7) > (In reply to Rafał Mużyło from comment #5) > > KDE strikes. > > > > The question is whether it needs to be a useflag and if so, will qtcore need > > [qt3support=]. > > Indeed, that needs to be investigated. It sounds weird to me that a qt > module hard-requires qt3support, but I cannot exclude it either. > That was meant "in either way". Obviously, it builds if qtgui[qt3support] and uses qt3suport symbols (if not the lib). Also, it builds with qtgui[-qt3support]. Now the thing to test is if it builds with forced no qt3support even if qtgui[qt3suport]. > > > > On that note: would it be possible to pull qt3to4 from qt3support into a > > separate package ? It doesn't need libQt3Support. > > Uhm...why? It's just a very very tiny utility, splitting doesn't seem worth > the effort... Well, I had this crazy idea that it would be possible to build porting qt3support tools without libQt3Suppport. Unfortunately, uic3 does require the lib and there seems to be no sane way to build the lib without qt3support symbols in the other libs (at least in ABI compatible way). Though qt3to4 is - as noted - clean in that regard.
*** Bug 477852 has been marked as a duplicate of this bug. ***
Same problem with -r2.
The problem is that the compiler is picking up the QDataStream(QByteArray *, int mode); constructor overload when QT3_SUPPORT is defined, instead of QDataStream(QByteArray *, QIODevice::OpenMode flags); which would be more appropriate (it's well known that C++ enums are quirky). The deprecated constructor is not needed since all callers actually pass a QIODevice::OpenMode, therefore I think we can just forcefully disable qt3support in qthelp.
(In reply to Davide Pesavento from comment #11) > therefore I think we can just forcefully disable > qt3support in qthelp. Now implemented. Please report back if it works or not, or if it eats you $pet.
-r2 still failing. build.log attached
Created attachment 354834 [details] build.log
(In reply to Oleg from comment #14) > Created attachment 354834 [details] > build.log Resync, your tree doesn't seem up to date.
