I was playing with accessibility use flag and when I was recompiling qt-declarative, I found that part of it tries to link agains system libQt5Quick.so.5 and compilation has failed. After removing qt-declarative, it emerged without problems Reproducible: Always Steps to Reproduce: As an example: 1. emerge -C qt-gui:5 qt-declarative:5 2. USE="accessibility" emerge -1 qt-gui:5 qt-declarative:5 3. Either use patch from bug #448628 of or add #define QT_NO_ACCESSIBILITY to /usr/include/qt5/Gentoo/gentoo-qconfig.h 4. USE="-accessibility" emerge -1 qt-gui:5 qt-declarative:5 Actual Results: Build of qt-declarative:5 fails
*** Bug 469478 has been marked as a duplicate of this bug. ***
I think we were discussing whether this is still an issue a while back and it seems it is - a user has reported this issue in #gentoo-qt for 5.1.0_beta1
*** Bug 480454 has been marked as a duplicate of this bug. ***
*** Bug 481252 has been marked as a duplicate of this bug. ***
*** Bug 472414 has been marked as a duplicate of this bug. ***
*** Bug 465872 has been marked as a duplicate of this bug. ***
*** Bug 489330 has been marked as a duplicate of this bug. ***
*** Bug 489514 has been marked as a duplicate of this bug. ***
*** Bug 490370 has been marked as a duplicate of this bug. ***
*** Bug 492510 has been marked as a duplicate of this bug. ***
*** Bug 494950 has been marked as a duplicate of this bug. ***
*** Bug 498894 has been marked as a duplicate of this bug. ***
I think I have made some small progress with this. Look at our link line: -lxslt -lz -ldl -lm -lgio-2.0 -lgstapp-0.10 -lgstinterfaces-0.10 -lgstpbutils-0.10 -lgstvideo- 0.10 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -pthread -lrt -lglib-2.0 -lxml2 -lsqlite3 -licui18n -licuuc -licudata -lQt5Quick -L/usr/lib64 -lQt5OpenGL -lQt5PrintSupport -L/var/tmp/portage/dev-qt/qtwebkit-5.9999/work/qtwebkit-5.9999_build/lib -lQt5WebKit -lQt5Qml -lQt5Widgets -lQt5Sql -lQt5Network -lQt5Gui -lQt5Core -lpthread -lXext -lX11 -lm -lGL So, /usr/lib64 is searched first, found, and failed before /var/tmp/portage/dev-qt/qtwebkit-5.9999/work/qtwebkit-5.9999_build/lib ever has a chance to be checked.
(In reply to Michael Palimaka (kensington) from comment #13) -L/usr/lib64 doesn't even need to be there since AFAIK it's searched by default as a fallback.
I was able to solve the "qwebpage.cpp:(.text._ZNK8QWebPage15visibilityStateEv+0x5): undefined reference to `QWebPageAdapter::visibilityState() const'" error by adding LIBS+=-L/var/tmp/portage/dev-qt/qtwebkit-5.9999/work/qtwebkit-5.9999/lib in Source/widgetsapi.pri
(In reply to Davide Pesavento from comment #14) > (In reply to Michael Palimaka (kensington) from comment #13) > > -L/usr/lib64 doesn't even need to be there since AFAIK it's searched by > default as a fallback. If we can remove this I guess it will just work.
Looking at qtmultimedia, I see a few variations: x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--no-undefined -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5MultimediaQuick_p.so.5 -o libQt5MultimediaQuick_p.so.5.3.0 .obj/qsgvideonode_p.o .obj/qdeclarativevideooutput.o .obj/qdeclarativevideooutput_render.o .obj/qdeclarativevideooutput_window.o .obj/qsgvideonode_i420.o .obj/qsgvideonode_rgb.o .obj/qsgvideonode_texture.o .obj/moc_qdeclarativevideooutput_p.o .obj/moc_qsgvideonode_p.o .obj/moc_qdeclarativevideooutput_render_p.o -lQt5Quick -L/usr/lib64 -L/var/tmp/portage/dev-qt/qtmultimedia-5.9999/work/qtmultimedia-5.9999_build/lib -lQt5Multimedia -lQt5Qml -lQt5Network -lQt5Gui -lQt5Core -lpthread -lGL x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--no-undefined -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5MultimediaWidgets.so.5 -o libQt5MultimediaWidgets.so.5.3.0 .obj/qcameraviewfinder.o .obj/qpaintervideosurface.o .obj/qvideowidgetcontrol.o .obj/qvideowidget.o .obj/qgraphicsvideoitem.o -L/var/tmp/portage/dev-qt/qtmultimedia-5.9999/work/qtmultimedia-5.9999_build/lib -lQt5Multimedia -lQt5Widgets -lQt5Network -lQt5Gui -lQt5Core -lpthread -lQt5OpenGL -L/usr/lib64 -lQt5Widgets -lQt5Gui -lQt5Core -lpthread -lGL I note that both the first and qtwebkit have -lQt5Quick -L/usr/lib64 so I wonder if it's caused whenever a particular module is pulled in.
Comparing old to new build logs, it looks like this isn't an issue anymore for qtbase. In some builds from mid-2013 -L/usr/lib64 is present, which is missing in current builds.
(In reply to Michael Palimaka (kensington) from comment #17) > > I note that both the first and qtwebkit have -lQt5Quick -L/usr/lib64 so I > wonder if it's caused whenever a particular module is pulled in. That's what I've been thinking too, that -L/usr/lib64 was pulled in via some other module... can you please check QMAKE_PRL_LIBS inside /usr/lib64/libQt5*.prl on your system?
Interestingly when I try to bisect the issue, I can't reproduce the -L/usr/lib64 in known-bad commits anymore.
(In reply to Davide Pesavento from comment #19) > (In reply to Michael Palimaka (kensington) from comment #17) > > > > I note that both the first and qtwebkit have -lQt5Quick -L/usr/lib64 so I > > wonder if it's caused whenever a particular module is pulled in. > > That's what I've been thinking too, that -L/usr/lib64 was pulled in via some > other module... can you please check QMAKE_PRL_LIBS inside > /usr/lib64/libQt5*.prl on your system? grep QMAKE_PRL_LIBS /usr/lib64/libQt5*.prl | grep "\-L/usr/lib64" /usr/lib64/libQt5Concurrent.prl:QMAKE_PRL_LIBS = -lrt -L/usr/lib64 -lQt5Core -lpthread /usr/lib64/libQt5MultimediaQuick_p.prl:QMAKE_PRL_LIBS = -lQt5Quick -L/usr/lib64 -L/usr/lib64 -lQt5Multimedia -lQt5Qml -lQt5Network -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5MultimediaWidgets.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Multimedia -lQt5Widgets -lQt5Network -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5OpenGLExtensions.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Gui -lQt5Core -lpthread -lGL /usr/lib64/libQt5PlatformSupport.prl:QMAKE_PRL_LIBS = -lfontconfig -lfreetype -L/usr/lib64 -lQt5Gui -lQt5Core -lpthread -lgthread-2.0 -pthread -lrt -lglib-2.0 -lXrender -lXext -lX11 -lm -lGL /usr/lib64/libQt5PrintSupport.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Widgets -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5QmlDevTools.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Core -lpthread /usr/lib64/libQt5QuickParticles.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Quick -lQt5Qml -lQt5Network -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5Quick.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Qml -lQt5Network -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5Script.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Core -lpthread /usr/lib64/libQt5WebKitWidgets.prl:QMAKE_PRL_LIBS = -L/tmp/ello -L/usr/lib64 -L/tmp/ohdear -lxslt -lz -ldl -lm -lgio-2.0 -lgstapp-0.10 -lgstinterfaces-0.10 -lgstpbutils-0.10 -lgstvideo-0.10 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -pthread -lrt -lglib-2.0 -lxml2 -lsqlite3 -licui18n -licuuc -licudata -lQt5Quick -L/usr/lib64 -lQt5OpenGL -lQt5PrintSupport -lQt5WebKit -lQt5Qml -lQt5Widgets -lQt5Sql -lQt5Network -lQt5Gui -lQt5Core -lpthread /usr/lib64/libQt5XmlPatterns.prl:QMAKE_PRL_LIBS = -L/usr/lib64 -lQt5Network -lQt5Core -lpthread
Hi, I compiled qtdeclararive manually, and found that the source of "-L/usr/lib64" is more likely the file qt_functions.prf. Here's what I get in qmake's debug output(with some lines from qt_functions.prf): DEBUG 1: /usr/lib64/qt5/mkspecs/qconfig.pri:8: QMAKE_DEFAULT_LIBDIRS := /usr/lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/lib /usr/lib/gcc/x86_64-pc-linux-gnu /lib /usr/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2 /usr/lib/gcc/lib64 /lib64 ... DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:170: calling qtAddModule(core, LIBS) DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:65: calling built-in $$eval(QT.core.libs) DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:65: MODULE_LIBS := /usr/lib64 (L78: MODULE_LIBS_ADD = $$MODULE_LIBS) DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:78: MODULE_LIBS_ADD := /usr/lib64 (!!L79: MODULE_LIBS_ADD -= $$QMAKE_DEFAULT_LIBDIRS (I wonder if this line works)) DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:79: MODULE_LIBS_ADD := /usr/lib64 ... DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:121: LINKAGE := -L/usr/lib64 ... DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:136: LIBS := -L/usr/lib64 -lQt5Core Maybe the token "-=" failed to work? But I didn't see any obvious bug in qmake's source code.
(In reply to Losier Blackheath from comment #22) > Hi, I compiled qtdeclararive manually, and found that the source of > "-L/usr/lib64" is more likely the file qt_functions.prf. > Here's what I get in qmake's debug output(with some lines from > qt_functions.prf): > > DEBUG 1: /usr/lib64/qt5/mkspecs/qconfig.pri:8: QMAKE_DEFAULT_LIBDIRS := > /usr/lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/lib > /usr/lib/gcc/x86_64-pc-linux-gnu /lib /usr/lib > /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2 /usr/lib/gcc/lib64 /lib64 > ... > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:170: calling > qtAddModule(core, LIBS) > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:65: calling > built-in $$eval(QT.core.libs) > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:65: MODULE_LIBS := > /usr/lib64 > (L78: MODULE_LIBS_ADD = $$MODULE_LIBS) > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:78: > MODULE_LIBS_ADD := /usr/lib64 > (!!L79: MODULE_LIBS_ADD -= $$QMAKE_DEFAULT_LIBDIRS (I wonder if this line > works)) > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:79: > MODULE_LIBS_ADD := /usr/lib64 > ... > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:121: LINKAGE := > -L/usr/lib64 > ... > DEBUG 1: /usr/lib64/qt5/mkspecs/features/qt_functions.prf:136: LIBS := > -L/usr/lib64 -lQt5Core > > Maybe the token "-=" failed to work? But I didn't see any obvious bug in > qmake's source code. I'm completely wrong. The QMAKE_DEFAULT_LIBDIRS above is aligned by /usr/lib64/qt5/mkspecs/qconfig.pri when host_build is false, and since qmlmin.CONFIG = host_build qmlimportscanner.CONFIG = host_build has been set in tools/tools.pro, QMAKE_DEFAULT_LIBDIRS is of course a null value.
I think that rather than trying to remove -L/usr/lib64, we should try to figure out why it appears before -L/var/tmp/portage/... in some cases. The former appears to be common behaviour even in other packages.
@pesa, do you know how the final link line is assembled from QMAKE_PRL_LIBS? I am guessing this is some dependency ordering issue (specific to qtwebkit apparently) but I don't really know what I'm looking for.
(In reply to Michael Palimaka (kensington) from comment #25) > @pesa, do you know how the final link line is assembled from QMAKE_PRL_LIBS? > I am guessing this is some dependency ordering issue (specific to qtwebkit > apparently) but I don't really know what I'm looking for. Not too well, but AFAIR everything should eventually end up in LIBS (a qmake var), then qmake c++ code assembles the final command line for the linker, but I suspect the ordering problem is already present in LIBS. So I'd start looking into the various .prf files involved (good luck with that).
(In reply to Davide Pesavento from comment #26) > (In reply to Michael Palimaka (kensington) from comment #25) > > @pesa, do you know how the final link line is assembled from QMAKE_PRL_LIBS? > > I am guessing this is some dependency ordering issue (specific to qtwebkit > > apparently) but I don't really know what I'm looking for. > > Not too well, but AFAIR everything should eventually end up in LIBS (a qmake > var), then qmake c++ code assembles the final command line for the linker, > but I suspect the ordering problem is already present in LIBS. So I'd start > looking into the various .prf files involved (good luck with that). Hey, I think the process that qmake generates .prl files should be checked and fixed. The building process can be omitted temporary. There's no other sources that produce "-L/usr/lib64".
(In reply to Losier Blackheath from comment #27) > Hey, I think the process that qmake generates .prl files should be checked > and fixed. The building process can be omitted temporary. There's no other > sources that produce "-L/usr/lib64". Yeah, they contain the -L/usr/lib64, but that's not necessarily wrong - for example many pkgconfig files also return that. It's not normally an issue because under normal circumstances -L/var/tmp/portage/... comes first.
(In reply to Michael Palimaka (kensington) from comment #28) > Yeah, they contain the -L/usr/lib64, but that's not necessarily wrong - for > example many pkgconfig files also return that. It's not normally an issue > because under normal circumstances -L/var/tmp/portage/... comes first. So maybe we have two choices: delete -L/usr/lib64 when generating .prl files, or deleting them when qmake is determing LIBS variable.
(In reply to Losier Blackheath from comment #29) > (In reply to Michael Palimaka (kensington) from comment #28) > > Yeah, they contain the -L/usr/lib64, but that's not necessarily wrong - for > > example many pkgconfig files also return that. It's not normally an issue > > because under normal circumstances -L/var/tmp/portage/... comes first. > > So maybe we have two choices: delete -L/usr/lib64 when generating .prl > files, or deleting them when qmake is determing LIBS variable. The former is easy but we probably can't do it because the prl files are installed and can be consumed by other packages. I don't know how possible the latter is, I think it's calculated at build time.
(In reply to Michael Palimaka (kensington) from comment #30) > The former is easy but we probably can't do it because the prl files are > installed and can be consumed by other packages. I don't know how possible > the latter is, I think it's calculated at build time. I found this in the Qt4's QMAKE_PRL_LIBS: QMAKE_PRL_LIBS = -L/usr/lib64 -L/usr/lib64/qt4 -L/usr/X11R6/lib -L/usr/lib64/qt4 -lQtCore -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -lpthread Now that -L/usr/lib64 exists in qt4's prl files, so maybe we can get to know how Qt4 handle them when generating makefiles.
Working from the other direction, apparently the -L/var/tmp/portage/... line comes from Tools/qmake/mkspecs/features/functions.prf:266 linkAgainstLibrary LIBS += -L$${ROOT_BUILD_DIR}/lib -l$$target) which is called from default_post.prf:201 needToLink linkAgainstLibrary($$library, $$eval(WEBKIT.$${library_identifier}.root_source_dir)) LIBS += $$eval(WEBKIT.$${library_identifier}.dependent_libs) Supposedly default_post.prf is run automatically by qmake, so maybe the needToLink conditional is failing for certain things.
(In reply to Michael Palimaka (kensington) from comment #32) > Working from the other direction, apparently the -L/var/tmp/portage/... line > comes from > > Tools/qmake/mkspecs/features/functions.prf:266 linkAgainstLibrary > LIBS += -L$${ROOT_BUILD_DIR}/lib -l$$target) > > which is called from > > default_post.prf:201 needToLink > linkAgainstLibrary($$library, > $$eval(WEBKIT.$${library_identifier}.root_source_dir)) > LIBS += $$eval(WEBKIT.$${library_identifier}.dependent_libs) > > Supposedly default_post.prf is run automatically by qmake, so maybe the > needToLink conditional is failing for certain things. I think qmake determines LIBS variable in its built-in routines, outer scripts only determines some sub-variables: ./generators/unix/unixmake2.cpp: t << "LIBS = $(SUBLIBS) " << var("QMAKE_LIBS") << " " << var("QMAKE_LIBS_PRIVATE") << endl; These variables didn't appear with any valuable information in the verbose log, so they should be aligned internally in qmake. But I can't get any more obvious clue now. Appending only one -d option to qmake makes a very huge build log, Appending another would be horrible.
I've scanned the source code of qmake, and was convinced that the inner routine of qmake processing .prl files is not controlled by .prf scripts: MakefileGenerator::processPrlFile(QString &file) reads the prl file and aligns QMAKE_PRL_LIBS to project->values("QMAKE_CURRENT_PRL_LIBS"); UnixMakefileGenerator::processPrlFiles() calles MakefileGenerator::processPrlFile(QString &file), then alignes project->values("QMAKE_CURRENT_PRL_LIBS") to "QMAKE_LIBS" and "QMAKE_LIBS_PRIVATE" string lists, like this: ProStringList &prl_libs = project->values("QMAKE_CURRENT_PRL_LIBS"); if(!prl_libs.isEmpty()) { for(int prl = 0; prl < prl_libs.size(); ++prl) l.insert(lit+prl+1, escapeFilePath(prl_libs.at(prl).toQString())); prl_libs.clear(); } UnixMakefileGenerator::writeMakeParts(QTextStream &t) writes "QMAKE_LIBS" and "QMAKE_LIBS_PRIVATE" into Makefile. A possible approach to solve this: Let qmake read /etc/ld.so.conf (or read QMAKE_DEFAULT_LIBDIRS) and maintain a string list of default library paths (with -L appended), and kill the listed items before inserting.
Maybe this patch works: diff -Naur makefile.cpp qmake/makefile.cpp1 --- qmake/generators/makefile.cpp 2014-02-02 04:37:29.000000000 +0800 +++ qmake/generators/makefile.cpp1 2014-03-26 20:55:03.593360015 +0800 @@ -304,10 +304,11 @@ else target_mode = TARG_UNIX_MODE; init(); - findLibraries(); + //findLibraries(); if(Option::qmake_mode == Option::QMAKE_GENERATE_MAKEFILE && project->isActiveConfig("link_prl")) //load up prl's' processPrlFiles(); + findLibraries(); } ProStringList Rebuilding these libraries takes some time, so I'm not sure whether it works. But I do know that codes in function findLibraries() can remove -L/usr/lib64 from "QMAKE_LIBS" and "QMAKE_LIBS_PRIVATE".
Unfortunately that patch didn't fix the issue for me.
The 'good' news is this appears to not be specific to us - I was able to see the same link path issue in SUSE builg logs too.
(In reply to Michael Palimaka (kensington) from comment #37) > The 'good' news is this appears to not be specific to us - I was able to see > the same link path issue in SUSE builg logs too. Good to know. I guess they don't actually run into a linking failure because they start with an "empty" system when building packages, right? i.e. there's no old version installed.
(In reply to Davide Pesavento from comment #38) > Good to know. I guess they don't actually run into a linking failure because > they start with an "empty" system when building packages, right? i.e. > there's no old version installed. Yeah, it looks like they populate a fresh kvm for every build.
This time I know where the problem is: There is a stupid mistake in UnixMakefileGenerator::findLibraries(), where int libidx is aligned to 0, and is used as the number of items in QList<QMakeLocalFileName> libdirs. Here is my solution: --- qmake/generators/unix/unixmake.cpp 2014-02-02 04:37:29.000000000 +0800 +++ qmake/generators/unix/unixmake-r2.cpp 2014-03-27 13:12:34.126192653 +0800 @@ -457,8 +457,10 @@ libArg.clear(); QList<QMakeLocalFileName> libdirs; int libidx = 0; - foreach (const ProString &dlib, project->values("QMAKE_DEFAULT_LIBDIRS")) + foreach (const ProString &dlib, project->values("QMAKE_DEFAULT_LIBDIRS")) { libdirs.append(QMakeLocalFileName(dlib.toQString())); + libidx++; + } static const char * const lflags[] = { "QMAKE_LIBS", "QMAKE_LIBS_PRIVATE", 0 }; for (int i = 0; lflags[i]; i++) { ProStringList &l = project->values(lflags[i]); I've rebuilt qtwebkit:5 with this bug(and one I posted yesterday), and I was happy to see that -L/usr/lib64s are removed like this: x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--no-undefined -fdebug-types-section -Wl,--gc-sections -Wl,--no-undefined -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5WebKitWidgets.so.5 -o libQt5WebKitWidgets.so.5.2.1 .obj/WebKit/qt/WidgetApi/qgraphicswebview.o .obj/WebKit/qt/WidgetApi/qwebframe.o .obj/WebKit/qt/WidgetApi/qwebpage.o .obj/WebKit/qt/WidgetApi/qwebview.o .obj/WebKit/qt/WidgetApi/qwebinspector.o .obj/WebKit/qt/WidgetSupport/QtFallbackWebPopup.o .obj/WebKit/qt/WidgetSupport/QtWebComboBox.o .obj/WebKit/qt/WidgetSupport/QWebUndoCommand.o .obj/WebKit/qt/WidgetSupport/InitWebKitQt.o .obj/WebKit/qt/WidgetSupport/InspectorClientWebPage.o .obj/WebKit/qt/WidgetSupport/PageClientQt.o .obj/WebKit/qt/WidgetSupport/QStyleFacadeImp.o .obj/WebKit/qt/WidgetSupport/QGraphicsWidgetPluginImpl.o .obj/WebKit/qt/WidgetSupport/QWidgetPluginImpl.o .obj/WebKit/qt/WidgetApi/qwebviewaccessible.o .obj/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/Source/.moc/moc_qwebinspector.o .obj/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/Source/.moc/moc_qwebkitplatformplugin.o .obj/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/Source/.moc/moc_InspectorClientWebPage.o .obj/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/Source/.moc/moc_QtFallbackWebPopup.o .obj/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/Source/.moc/moc_QtWebComboBox.o -lxslt -lz -ldl -lm -lrt -lxml2 -lgio-2.0 -lgstapp-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lgstaudio-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lsqlite3 -licui18n -licuuc -licudata -lQt5Quick -lQt5OpenGL -L/var/tmp/portage/dev-qt/qtwebkit-5.2.1/work/qtwebkit-opensource-src-5.2.1_build/lib -lQt5WebKit -lQt5Qml -lQt5Widgets -lQt5Sql -L/usr/lib64/mysql -lQt5Network -lQt5Gui -lQt5Core -lpthread -lXext -lX11 -lm -lGL Now tell upstream about this and they will fix it in their official versions.
Patch works for me too, what do you think, pesa?
I'm not too familiar with qmake C++ code, but the patch makes a lot of sense. As a matter of fact, a few lines below in processPrlFiles() there's a very similar logic, only this time the duplicate test is a simple '.contains()' rather than '.indexOf() + index comparison', thus processPrlFiles() is not affected by this bug. Can you submit a patch to https://codereview.qt-project.org/ please? Or I can do it if you don't want to deal with gerrit or the CLA.
So, is this bug in progress now? Or are there still some other issues here?
(In reply to Losier Blackheath from comment #43) > So, is this bug in progress now? Or are there still some other issues here? My question in comment #42 was addressed to you. Can you submit a patch to https://codereview.qt-project.org/ please? Or I can do it if you don't want to deal with gerrit or accept the CLA.
I've reported the bug in bugreports.qt-project.org, ID: QTBUG-37963
Thanks.
Davide can you put it on gerrit? It will probably just rot on the bugtracker. I would have done it already except I am blocked by bug #483498.
(In reply to Michael Palimaka (kensington) from comment #47) > Davide can you put it on gerrit? It will probably just rot on the > bugtracker. I would have done it already except I am blocked by bug #483498. Agree, but my network condition does not allow me to do jobs like git pull at present. So maybe someone else may help with this.
I'll do it, just give me a few days, I'm busy with RL this week.
Upstream says that the index is fixed in commit qtbase/5bc9541e7a3a55849020d79ee7d7b4d0996ce2ff, but I don't have the latest development version. Tell me whether the issue is fixed there.
According to git tag, that commit is included since 5.0.0-beta1, so I guess it's broken again.
(In reply to Michael Palimaka (kensington) from comment #51) > According to git tag, that commit is included since 5.0.0-beta1, so I guess > it's broken again. Not necessarily. Our interpretation of that code could be completely wrong.
Well, what that commit says it does is not consistent with the current behaviour at least.
Well, I misunderstood the code in findLibraries(), I thought they were used to delete system paths. So maybe we need to insert this function into processPrlFiles().
"you'll get an execution trace by going to the webkit build dir and running QMAKEFLAGS=-d make -f Makefile.... qmake >& qmake.log. have fun ..." Can someone do this and attach the log file please? I already tried this some time ago and failed to find the cause, but things have changed so...
Well, I have this build log with -d option(267 MiB), and one with 2 -ds(385 MiB), they are too large and will use up my flow. So I'll attach them tomorrow.
(In reply to Losier Blackheath from comment #56) I don't need the whole build.log, just the qmake debug log (possibly compressed with xz). Remember to run 'ebuild qtwebkit-5<...>.ebuild configure' before.
Created attachment 374270 [details] qmake's debug log Here's qmake's log. btw, if you want qmake to produce verbose debug log, just patch qt5-build.eclass. --- qt5-build.eclass 2014-03-29 10:50:19.000000000 +0800 +++ qt5-build-r1.eclass 2014-04-03 15:57:45.327435363 +0800 @@ -514,7 +514,7 @@ qt5_qmake() { local projectdir=${PWD/#${QT5_BUILD_DIR}/${S}} - "${QT5_BUILD_DIR}"/bin/qmake "${projectdir}" \ + "${QT5_BUILD_DIR}"/bin/qmake "${projectdir}" -d \ || die "qmake failed (${projectdir})" }
https://codereview.qt-project.org/83476
Upstream patches have been merged to the stable branch. Can someone test with 5.3.9999 please?
(In reply to Davide Pesavento from comment #60) > Upstream patches have been merged to the stable branch. Can someone test > with 5.3.9999 please? step from #c1 now work now with 5.3.9999
-L/usr/lib64 disappears from prl files in 5.3.9999.
(In reply to Francesco Riosa from comment #61) > step from #c1 now work now with 5.3.9999 (In reply to Losier Blackheath from comment #62) > -L/usr/lib64 disappears from prl files in 5.3.9999. Great! I'll backport the patchset to 5.3.0* asap then.
*** Bug 507014 has been marked as a duplicate of this bug. ***
Fixed in git https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commit;h=70c3a1179797cd8c09c6894e4c34640212511766 Thanks a lot to everyone involved!
This issue has reappeared for qtsql only: x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--no-undefined -shared -o libqsqlmysql.so .obj/main.o .obj/qsql_mysql.o .obj/moc_qsql_mysql_p.o -L/usr/lib64/mysql -Wl,-O1 -Wl,--as-needed -m64 -rdynamic -lmysqlclient_r -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto -L/var/tmp/portage/dev-qt/qtsql-5.3.0_rc/work/qtbase-opensource-src-5.3.0-RC/lib -lQt5Sql -lQt5Core -lpthread .obj/qsql_mysql.o: In function `QMYSQLDriver::QMYSQLDriver(QObject*)': qsql_mysql.cpp:(.text+0x34c1): undefined reference to `QSqlError::QSqlError(QString const&, QString const&, QSqlError::ErrorType, QString const&)'
What are you doing exactly? Upgrading from what version to what version?
It was an upgrade from 5.2.1 to 5.3.0_rc, with the fixed qtcore already merged.
I suppose qtsql is using the mkspecs dir in ${S} rather than the installed one which contains the fixed .prf files. Can you try applying the 7 qtcore patches to qtsql too?
There's no change with the patches applied. It appears to be caused by mysql, and looks like QT_LFLAGS_MYSQL is populated by mysql_config --libs which outputs here -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -rdynamic -L/usr/lib64/mysql -lmysqlclient -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto So it looks like filterLibraryOptions in configure isn't working as expected.
The qtsql issue has a different cause then, let's continue in bug 511042.
