I've emerged the QT4 beta2 to experiment with it, and I use QT3 for the Gentoo system and everything else. QT4's qmake is installed in /usr/bin, so I had to ensure that: - QTDIR=/usr/qt/3 - /usr/qt/3/bin appears before /usr/bin in $PATH So when I invoke qmake, the QT3 version is called, and gets the right QTDIR value. To use QT4, I call kdevelop with: bash -c "PATH=/usr/bin:$PATH QTDIR=/usr/lib/qt4 kdevelop" It works well.. but it fails on some ebuilds. For example, libfwbuilder (2.0.6 and 2.0.7): Running qmake... Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. Unable to find a Qt configuration. !!! Please attach the config.log to your bug report: !!! /var/tmp/portage/libfwbuilder-2.0.7/work/libfwbuilder-2.0.7/config.log !!! ERROR: net-libs/libfwbuilder-2.0.7 failed. !!! Function econf, Line 485, Exitcode 0 !!! econf failed !!! If you need support, post the topmost build error, NOT this status message. So, is there a better way to have QT4 installed aside, and let QT3 be used by default when emerging everything ? Thanks
>qt-4.0.0_beta2 qmake in /usr/bin why ? /usr/qt/ is not a FHS
>qt-4.0.0_beta2 qmake in /usr/bin why ? /usr/qt/ is not a FHS¹ compliant path. >So, is there a better way to have QT4 installed aside, and let QT3 be used by default when emerging everything ? Qt 4 is still hard masked, so fixing this is not urgent. I'm sure Caleb will have a look at it, when he's back from vacation. [1] http://www.pathname.com/fhs/
Thanks for your response ! The FHS is an interesting read. Just a temporary solution for those hitting the problem before Caleb comes back: to emerge fwbuilder, just temporarily rename /usr/bin/qmake to something else.
*** Bug 93406 has been marked as a duplicate of this bug. ***
It's proper to put the binaries into /usr/bin, however, they will indeed conflict with Qt3 binaries (in /usr/qt/3/bin) in some instances (like qmake). Suggestions are welcome.
I might recommend you try out the latest beta2-r2 and see if that doesn't help with these problems.
I tried, but I get this strange result: /var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/bin/moc -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_SHARED -I/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/mkspecs/linux-g++ -I. -I../../../include/QtGui -I../../../include/QtCore -I../../../include -I.moc/release-shared -I. previewwindow.h -o .moc/release-shared/moc_previewwindow.cpp g++ -c -pipe -I/usr/include/mysql -pipe -march=pentium-m -O2 -Wall -W -D_REENTRANT -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_SHARED -I/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/mkspecs/linux-g++ -I. -I../../../include/QtGui -I../../../include/QtCore -I../../../include -I.moc/release-shared -I. -o .obj/release-shared/moc_controllerwindow.o .moc/release-shared/moc_controllerwindow.cpp g++ -c -pipe -I/usr/include/mysql -pipe -march=pentium-m -O2 -Wall -W -D_REENTRANT -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_SHARED -I/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/mkspecs/linux-g++ -I. -I../../../include/QtGui -I../../../include/QtCore -I../../../include -I.moc/release-shared -I. -o .obj/release-shared/moc_previewwindow.o .moc/release-shared/moc_previewwindow.cpp g++ -Wl,-O1 -Wl,--sort-common -o windowflags .obj/release-shared/controllerwindow.o .obj/release-shared/previewwindow.o .obj/release-shared/main.o .obj/release-shared/moc_controllerwindow.o .obj/release-shared/moc_previewwindow.o -L/usr/lib/mysql -L/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/lib -L/usr/lib/mysql -L/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/lib -lQtGui -L/usr/X11R6/lib -lpng -lSM -lICE -lXi -lXrender -lXrandr -lXcursor -lfreetype -lfontconfig -lXext -lX11 -lm -lQtCore -lz -ldl -lpthread make[3]: Leaving directory `/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/examples/widgets/windowflags' make[2]: Leaving directory `/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/examples/widgets' make[1]: Leaving directory `/var/tmp/portage/qt-4.0.0_beta2-r2/work/qt-x11-opensource-4.0.0-rc1-snapshot-20050523/examples' !!! ERROR: x11-libs/qt-4.0.0_beta2-r2 failed. !!! Function src_compile, Line 122, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
Are you using the examples use flag? I haven't tested that one in a while.
Yes, indeed (funny I didn't even think of it) Trying to re-emerge now :-)
The _rc1 ebuild still puts stuff into /usr/bin: (0) otherland image # ls usr/bin/ assistant linguist lupdate qm2ts qt3to4 rcc uic3 designer lrelease moc qmake qtconfig uic I'm glad I didn't merge it yet, dunno how the rest of the system might react :) The /usr/qt path is not FHS compliant (and I don't really like it) but I think it's currently the only safe way to have both versions on one system. An alternative could be a qt-config script to switch between the versions. The binaries could go to /usr/lib/qt4/bin which might be FHS compliant.
I've been running it on a production system lately with no bad side effects. It seems that KDE scripts, et al., that rely on qt3 tools find the proper ones as long as you have QTDIR set correctly. qmake seems to find the proper files as well. If the ebuild was changed to install into /usr/qt/4/bin, however, I'm not sure how would that be different than /usr/bin, assuming that the problematic issues stem from when the tools are found in the PATH and not via some other means.
Note: In an early incarnation of the qt4 ebuild I put the binaries into /usr/lib/qt4/bin, but was told that this isn't a very proper way to do it (not sure if that was 'Gentoo proper' or 'FHS proper') and to instead put library realted binaries into /usr/libexec. Also, the qmake 'Unable to find a Qt configuration.' seems to have disappeared since _rc1.
Ok, I'll merge the _rc1 and see what breaks :) About /usr/libexec: That's a GNU extension damned by the FHS maintainers (the one I talked with last preferred /usr/lib/bin). But I think it's more like a question of fancy, like /svc and the GPL itself :)
These are the programs that would be affected: moc qmake uic Because all of the others (assistant, designer, etc.) are run manually. So, I suppose it'll be good to make sure that various build scripts call the correct versions of the above programs.
qmake for Qt3 defines: MOC=$QTDIR/bin/moc UIC=$QTDIR/bin/uic Whereas it is defined via .prf files for qmake from Qt4, so it looks like that for .pro based projects as long as we call the correct qmake all should be okay. The KDE build scripts seem to find the correct moc and uic programs as well, so I think we're safe there. Now, to make sure that the correct qmake is used...
I don't have any qmake-based projects to test with, but I think the (qt3) examples should be a good testcase. Actually, the only tools I have issues with are designer et al: mss@otherland ~ $ designer designer: error while loading shared libraries: libQtDesigner.so.4: cannot open shared object file: No such file or directory mss@otherland ~ $ LD_LIBRARY_PATH=/usr/lib/qt4 designer mss@otherland ~ $ <http://doc.trolltech.com/4.0/install-x11.html> says: For compilers that do not support rpath you must also extended the LD_LIBRARY_PATH environment variable to include /usr/local/Trolltech/Qt-4.0.0-rc1/lib. On Linux with GCC this step is not needed. Should I open a separate bug for this?
Shouldn't have to, you can just do a: su (enter root password) ld-config exit and it should work fine.
Make that 'ldconfig' not 'ld-config'
Already did so, but as /usr/lib/qt4 isn't in /etc/ld.so.conf, it didn't change anything. I could add the dir there but the Qt page suggests that it should work automagically without such an entry.
Hmm, did you get a /etc/env.d/44qt4 file after emerging? Now that I think about it, I think I manually created it on my system.
Nope, the image only contained a /usr. I had a look at the ebuild, seems like the file should be created in the end. But as there is no directory etc/env.d in the image, the cat probably fails. Maybe the QTSYSCONFDIR should be created, too. About the trolltech page: I guess the rpath magic is disabled by the qt4-rpath.patch? Just out of interest (and pretty OT), do you have a link to a description why this is done and what the rpath does in the first place?
It may need to be re-evaluated (perhaps things have been changed since the first qt4 preview release). rpath basically locks in a library location within a binary, so you can tell 'uic', for example, where the Qt4 libraries are located without it having to resort to using the dynamic linker to find them. The problem is that, with the Gentoo system, it uses the portage temporary stuff to lock in. That is, uic links against /var/tmp/portage/.../libQt.so. So, even after installing Qt it is still going to look in /var/tmp/portage for that library. When it doesn't find it there, then it will resort to the dynamic linker to find it. The problem is, this is a security breach, since someone could put a malicious libQt.so in /var/tmp/portage and come up with crafty ways to exploit the system. So we just disable rpath all-together since it doesn't work in the intended way in the first place.
I think that we'll leave it putting the programs in /usr/bin
*** Bug 100463 has been marked as a duplicate of this bug. ***
