>>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-python/PyQt4-4.9.1/work/PyQt-x11-gpl-4.9.1 ... * Configuration of dev-python/PyQt4-4.9.1 with CPython 2.7... python2.7 configure.py --confirm-license --bindir=/opt/scisoft64/usr/bin --destdir=/opt/scisoft64/usr/lib/python2.7/site-packages --sipdir=/opt/scisoft64/usr/share/sip --assume-shared --no-timestamp --qsci-api --enable=QtCore --enable=QtNetwork --enable=QtScript --enable=QtXml --enable=QtGui --enable=QtDesigner --enable=QtScriptTools --enable=QtTest --enable=QtHelp --enable=QtOpenGL --enable=QtSql --enable=QtSvg CC=x86_64-pc-linux-gnu-gcc CXX=x86_64-pc-linux-gnu-g++ LINK=x86_64-pc-linux-gnu-g++ LINK_SHLIB=x86_64-pc-linux-gnu-g++ CFLAGS=-O2 -pipe -march=core2 -mssse3 -frecord-gcc-switches -g CXXFLAGS=-O2 -pipe -march=core2 -mssse3 -frecord-gcc-switches -g LFLAGS=-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common Determining the layout of your Qt installation... Error: ./qtdirs failed to create qtdirs.out. Make sure your Qt v4 installation is correct. * ERROR: dev-python/PyQt4-4.9.1 failed (configure phase): * (no error message) * * Call stack: * ebuild.sh, line 85: Called call-ebuildshell 'src_configure' * environment, line 1232: Called src_configure * environment, line 5054: Called python_execute_function '-s' 'configuration' * environment, line 3350: Called configuration * environment, line 5039: Called die * The specific snippet of code: * "${myconf[@]}" || die; Any ideas how to debug? I asume that libqt* aren't available for linking.
okay, programs do simply not get linked correctly against qt4. What could be worng here? On my other system it works.
If you look into /var/tmp/portage/dev-python/PyQt4-4.9.1/work/PyQt-x11-gpl-4.9.1, do you have the qtdirs-executable there? Did you get qtdirs.out? If qtdirs (binary) exists, but no qtdirs.out, the file just could not get created. QFile creates the file, nevertheless you write to it or not. If you copy the qtdirs.cpp (gets created by configure.py) into your HOME, compile it g++ qtdirs.cpp -o qtdirs -I/usr/include/qt4 -I/usr/include/qt4/QtCore -L/usr/lib64/qt4 -lQtCore and execute it, does it create a non-empty qtdirs.out?
qtdirs isn't created. If I call python configure.py ... manually or compile it like you said, it gets build but if I execute it, I get $ ./qtdirs ./qtdirs: error while loading shared libraries: libQtCore.so.4: cannot open shared object file: No such file or directory
$ ldd -r qtdirs linux-vdso.so.1 => (0x00007fffb116c000) libQtCore.so.4 => not found libstdc++.so.6 => /opt/scisoft64/usr/x86_64-pc-linux-gnu/lib/gcc/libstdc++.so.6 (0x00002b36bc99c000) libgcc_s.so.1 => /opt/scisoft64/lib/libgcc_s.so.1 (0x00002b36bcca0000) libc.so.6 => /lib64/libc.so.6 (0x00002b36bceb6000) libm.so.6 => /lib64/libm.so.6 (0x00002b36bd247000) /lib64/ld-linux-x86-64.so.2 (0x00002b36bc779000) undefined symbol: _ZN11QTextStreamlsEPKc (./qtdirs) undefined symbol: _ZN16QCoreApplicationD1Ev (./qtdirs) undefined symbol: _ZN11QTextStreamlsEi (./qtdirs) undefined symbol: _ZN5QFileD1Ev (./qtdirs) undefined symbol: _ZN7QString16fromAscii_helperEPKci (./qtdirs) undefined symbol: _ZN16QCoreApplicationC1ERiPPci (./qtdirs) undefined symbol: _ZN11QTextStreamD1Ev (./qtdirs) undefined symbol: _ZN11QTextStreamlsEc (./qtdirs) undefined symbol: _ZN5QFileC1ERK7QString (./qtdirs) undefined symbol: _ZN11QTextStreamC1EP9QIODevice (./qtdirs) undefined symbol: _ZN12QLibraryInfo8locationENS_15LibraryLocationE (./qtdirs) undefined symbol: _ZN11QTextStreamlsERK7QString (./qtdirs) undefined symbol: _ZN12QLibraryInfo8licenseeEv (./qtdirs) undefined symbol: _ZN5QFile4openE6QFlagsIN9QIODevice12OpenModeFlagEE (./qtdirs) undefined symbol: _ZN7QString4freeEPNS_4DataE (./qtdirs)
Could you run VERBOSE="1" emerge PyQt4 and look for the qmake-binary. I assume yours is in /opt/scisoft64/usr/bin, but configure.py assumes it is inside /usr/bin: $ python configure.py --help | grep qmake -q FILE, --qmake=FILE the pathname of qmake [default: /usr/bin/qmake] You could try to add --qmake="${EPREFIX}/usr/bin/qmake" to myconf in src_configure.
(In reply to comment #5) > Could you run > VERBOSE="1" emerge PyQt4 that isn't more verbose as standard > $ python configure.py --help | grep qmake > -q FILE, --qmake=FILE > the pathname of qmake [default: /usr/bin/qmake] this is already EPREFX/usr/bin/qmake, so no benefit. in general I think the typical prefix magic is missing if thinks are outside EPREFIX/usr/lib. Probably a broken toolchain or so. Currently I am rebuilding everything, but with little hope.
The problem is in EPREFIX/usr/share/qt4/mkspecs/gentoo/config.pri. In old version QMAKE_RPATHDIR += "/opt/scisoft64/usr/lib/qt4" was added. @qt4-team do you see any place where the change could come from?
Is this a regression? Since when? Which qt-core versions are we talking about here?
Uhm, I suspect this is a side effect of the change introduced in Qt 4.8.x for bug 380415. And I guess prefix systems ignore the env.d file installed by qt-core, right?
I hit this with 4.8.1 onwards and it is a regression. But on needs to rebuild revdeps to hit it. in case you are not familiar with prefix, a problem is that we cannot control the ld.conf, so any LDPATH entry which can be used in a general installation, is useless for us. So we need to have the rpath entry.
(In reply to comment #9) > Uhm, I suspect this is a side effect of the change introduced in Qt 4.8.x > for bug 380415. Right this one breaks it on prefix.
(In reply to comment #10) > in case you are not familiar with prefix, a problem is that we cannot > control the ld.conf, so any LDPATH entry which can be used in a general > installation, is useless for us. So we need to have the rpath entry. That's very bad... Any other solutions that work on both prefix and non-prefix? BTW I wonder how it was possible that this breakage has been discovered so late (5 months after the change)...
Most probably because qt48 wasn't merged into prefix at that time.
(In reply to comment #12) > That's very bad... Any other solutions that work on both prefix and > non-prefix? > Why are they installed into a subdir of libdir anyways?
(In reply to comment #14) > (In reply to comment #12) > > That's very bad... Any other solutions that work on both prefix and > > non-prefix? > > > > Why are they installed into a subdir of libdir anyways? I think because of multiple versions support (qt3 vs qt4 vs qt5)
Can we add the RAPTH support prefix depend?
(In reply to comment #16) > Can we add the RAPTH support prefix depend? Yes, that's doable of course.
Created attachment 313005 [details, diff] qt4-rpath-prefix.patch This patch should revert rpath to 4.7 behavior on prefix.
prefix devs, what do you say to this? I think until we found another solution, we should take this? Which breakage need to be expected?
I think that does the trick, thanks
I just tested it and everything is fine. @qt, please patch the eclass, thanks.
Applied.
