Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 451456 - [qt overlay] Qt5 packages (dev-qt/qt*:5) try to link against already installed versions during recompilation
Summary: [qt overlay] Qt5 packages (dev-qt/qt*:5) try to link against already installe...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Highest critical with 2 votes (vote)
Assignee: Qt Bug Alias
URL: https://bugreports.qt-project.org/bro...
Whiteboard:
Keywords: PATCH, UPSTREAM
: 465872 469478 472414 480454 481252 489330 489514 490370 492510 494950 507014 (view as bug list)
Depends on:
Blocks: qt5-porting
  Show dependency tree
 
Reported: 2013-01-11 21:01 UTC by Eugene Shalygin
Modified: 2016-02-17 21:39 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
qmake's debug log (qmake-debug.tar.xz,349.41 KB, text/plain)
2014-04-05 03:11 UTC, Losier Blackheath
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Shalygin 2013-01-11 21:01:19 UTC
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
Comment 1 Michael Palimaka (kensington) gentoo-dev 2013-05-12 13:10:41 UTC
*** Bug 469478 has been marked as a duplicate of this bug. ***
Comment 2 Michael Palimaka (kensington) gentoo-dev 2013-06-23 13:06:38 UTC
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
Comment 3 Davide Pesavento gentoo-dev 2013-08-16 07:37:48 UTC
*** Bug 480454 has been marked as a duplicate of this bug. ***
Comment 4 Davide Pesavento gentoo-dev 2013-08-16 07:38:24 UTC
*** Bug 481252 has been marked as a duplicate of this bug. ***
Comment 5 Davide Pesavento gentoo-dev 2013-10-06 10:55:13 UTC
*** Bug 472414 has been marked as a duplicate of this bug. ***
Comment 6 Davide Pesavento gentoo-dev 2013-10-06 10:56:27 UTC
*** Bug 465872 has been marked as a duplicate of this bug. ***
Comment 7 Davide Pesavento gentoo-dev 2013-10-27 17:19:12 UTC
*** Bug 489330 has been marked as a duplicate of this bug. ***
Comment 8 Davide Pesavento gentoo-dev 2013-10-27 19:29:01 UTC
*** Bug 489514 has been marked as a duplicate of this bug. ***
Comment 9 Davide Pesavento gentoo-dev 2013-11-06 18:51:14 UTC
*** Bug 490370 has been marked as a duplicate of this bug. ***
Comment 10 Davide Pesavento gentoo-dev 2013-11-27 11:38:28 UTC
*** Bug 492510 has been marked as a duplicate of this bug. ***
Comment 11 Davide Pesavento gentoo-dev 2013-12-21 18:08:54 UTC
*** Bug 494950 has been marked as a duplicate of this bug. ***
Comment 12 Michael Palimaka (kensington) gentoo-dev 2014-01-22 14:54:54 UTC
*** Bug 498894 has been marked as a duplicate of this bug. ***
Comment 13 Michael Palimaka (kensington) gentoo-dev 2014-02-10 16:35:38 UTC
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.
Comment 14 Davide Pesavento gentoo-dev 2014-02-10 17:30:50 UTC
(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.
Comment 15 Michael Palimaka (kensington) gentoo-dev 2014-02-10 17:37:14 UTC
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
Comment 16 Michael Palimaka (kensington) gentoo-dev 2014-02-11 08:23:56 UTC
(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.
Comment 17 Michael Palimaka (kensington) gentoo-dev 2014-02-11 17:07:40 UTC
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.
Comment 18 Michael Palimaka (kensington) gentoo-dev 2014-02-11 17:26:14 UTC
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.
Comment 19 Davide Pesavento gentoo-dev 2014-02-11 17:32:36 UTC
(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?
Comment 20 Michael Palimaka (kensington) gentoo-dev 2014-02-11 18:23:34 UTC
Interestingly when I try to bisect the issue, I can't reproduce the -L/usr/lib64 in known-bad commits anymore.
Comment 21 Michael Palimaka (kensington) gentoo-dev 2014-02-11 18:24:33 UTC
(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
Comment 22 Losier Blackheath 2014-02-16 01:34:09 UTC
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.
Comment 23 Losier Blackheath 2014-02-17 10:23:38 UTC
(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.
Comment 24 Michael Palimaka (kensington) gentoo-dev 2014-03-11 11:45:39 UTC
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.
Comment 25 Michael Palimaka (kensington) gentoo-dev 2014-03-11 14:35:53 UTC
@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.
Comment 26 Davide Pesavento gentoo-dev 2014-03-11 18:46:35 UTC
(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).
Comment 27 Losier Blackheath 2014-03-13 13:10:12 UTC
(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".
Comment 28 Michael Palimaka (kensington) gentoo-dev 2014-03-13 13:35:37 UTC
(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.
Comment 29 Losier Blackheath 2014-03-13 13:41:20 UTC
(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.
Comment 30 Michael Palimaka (kensington) gentoo-dev 2014-03-13 14:24:40 UTC
(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.
Comment 31 Losier Blackheath 2014-03-13 14:31:59 UTC
(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.
Comment 32 Michael Palimaka (kensington) gentoo-dev 2014-03-13 14:34:45 UTC
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.
Comment 33 Losier Blackheath 2014-03-13 15:35:18 UTC
(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.
Comment 34 Losier Blackheath 2014-03-14 05:34:23 UTC
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.
Comment 35 Losier Blackheath 2014-03-26 13:30:18 UTC
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".
Comment 36 Michael Palimaka (kensington) gentoo-dev 2014-03-26 15:09:20 UTC
Unfortunately that patch didn't fix the issue for me.
Comment 37 Michael Palimaka (kensington) gentoo-dev 2014-03-26 15:37:29 UTC
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.
Comment 38 Davide Pesavento gentoo-dev 2014-03-26 15:40:02 UTC
(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.
Comment 39 Michael Palimaka (kensington) gentoo-dev 2014-03-26 15:43:35 UTC
(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.
Comment 40 Losier Blackheath 2014-03-27 07:56:01 UTC
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.
Comment 41 Michael Palimaka (kensington) gentoo-dev 2014-03-27 11:07:41 UTC
Patch works for me too, what do you think, pesa?
Comment 42 Davide Pesavento gentoo-dev 2014-03-27 17:38:21 UTC
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.
Comment 43 Losier Blackheath 2014-03-29 00:54:59 UTC
So, is this bug in progress now? Or are there still some other issues here?
Comment 44 Davide Pesavento gentoo-dev 2014-03-29 01:14:39 UTC
(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.
Comment 45 Losier Blackheath 2014-03-29 02:39:10 UTC
I've reported the bug in bugreports.qt-project.org, ID: QTBUG-37963
Comment 46 Davide Pesavento gentoo-dev 2014-03-29 03:26:26 UTC
Thanks.
Comment 47 Michael Palimaka (kensington) gentoo-dev 2014-03-29 13:42:55 UTC
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.
Comment 48 Losier Blackheath 2014-03-30 05:48:26 UTC
(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.
Comment 49 Davide Pesavento gentoo-dev 2014-03-30 14:44:32 UTC
I'll do it, just give me a few days, I'm busy with RL this week.
Comment 50 Losier Blackheath 2014-04-02 10:11:20 UTC
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.
Comment 51 Michael Palimaka (kensington) gentoo-dev 2014-04-02 12:40:16 UTC
According to git tag, that commit is included since 5.0.0-beta1, so I guess it's broken again.
Comment 52 Davide Pesavento gentoo-dev 2014-04-02 14:37:31 UTC
(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.
Comment 53 Michael Palimaka (kensington) gentoo-dev 2014-04-02 14:38:34 UTC
Well, what that commit says it does is not consistent with the current behaviour at least.
Comment 54 Losier Blackheath 2014-04-02 14:57:15 UTC
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().
Comment 55 Davide Pesavento gentoo-dev 2014-04-02 15:36:20 UTC
"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...
Comment 56 Losier Blackheath 2014-04-02 15:49:29 UTC
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.
Comment 57 Davide Pesavento gentoo-dev 2014-04-05 02:18:53 UTC
(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.
Comment 58 Losier Blackheath 2014-04-05 03:11:55 UTC
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})"
 }
Comment 59 Davide Pesavento gentoo-dev 2014-04-14 17:06:44 UTC
https://codereview.qt-project.org/83476
Comment 60 Davide Pesavento gentoo-dev 2014-04-15 20:35:27 UTC
Upstream patches have been merged to the stable branch. Can someone test with 5.3.9999 please?
Comment 61 Francesco Riosa 2014-04-16 15:44:23 UTC
(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
Comment 62 Losier Blackheath 2014-04-25 11:42:56 UTC
-L/usr/lib64 disappears from prl files in 5.3.9999.
Comment 63 Davide Pesavento gentoo-dev 2014-04-25 13:14:18 UTC
(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.
Comment 64 Elias Probst 2014-05-07 18:56:09 UTC
*** Bug 507014 has been marked as a duplicate of this bug. ***
Comment 65 Davide Pesavento gentoo-dev 2014-05-12 16:34:37 UTC
Fixed in git
https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commit;h=70c3a1179797cd8c09c6894e4c34640212511766

Thanks a lot to everyone involved!
Comment 66 Michael Palimaka (kensington) gentoo-dev 2014-05-20 16:21:55 UTC
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&)'
Comment 67 Davide Pesavento gentoo-dev 2014-05-20 17:11:11 UTC
What are you doing exactly? Upgrading from what version to what version?
Comment 68 Michael Palimaka (kensington) gentoo-dev 2014-05-20 17:16:51 UTC
It was an upgrade from 5.2.1 to 5.3.0_rc, with the fixed qtcore already merged.
Comment 69 Davide Pesavento gentoo-dev 2014-05-20 17:35:26 UTC
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?
Comment 70 Michael Palimaka (kensington) gentoo-dev 2014-05-22 15:44:26 UTC
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.
Comment 71 Davide Pesavento gentoo-dev 2014-05-22 16:04:55 UTC
The qtsql issue has a different cause then, let's continue in bug 511042.