2012/2/1 Darrell Anderson <humanreadable@...>: >> I know that there were some changes >> in this filed with the >> introduction of TQt with already translated Q* objects to >> QT*. But I >> have I noticed on my system another thing having both >> qt3.3.8d and >> qt4.8.0 installed and I don't know if there are movements to >> resolve >> this. >> >> Qt provides set of tools that enable creation of qt-based >> applications. Those are: assistant, designer, linguist , >> lrelease, >> lupdate, moc, qmake, qtconfig, uic. Those are provided both >> by qt4 and >> our qt3. >> If I have both of the qt versions installed and I try to run >> one of >> those applications, only the qt4 versions are launched, and >> I am >> unable to launch qt3 ones unless i specify full path to them >> as >> command. >> That may be because I installed qt4 as second, and if I were >> to >> install it first and then qt3 then I'd be able to start only >> those >> provided by qt3. >> If I run those commands through whereis I get: >> >> assistant: /usr/bin/assistant /opt/qt/bin/assistant >> designer: /usr/bin/designer /opt/qt/bin/designer >> linguist: /usr/bin/linguist /opt/qt/bin/linguist >> lrelease: /usr/bin/lrelease /opt/qt/bin/lrelease >> lupdate: /usr/bin/lupdate /opt/qt/bin/lupdate >> moc: /usr/bin/moc /opt/qt/bin/moc >> qmake: /usr/bin/qmake /opt/qt/bin/qmake >> qtconfig: /usr/bin/qtconfig /opt/qt/bin/qtconfig >> >> Obviously, if I invoke assistant, the first path is >> executed. >> >> As a temporary solution for my packages I create links to >> the qt3 >> tools in $prefix/bin/ and name them in the Qt3* scheme. >> Anyway I think >> those should be renamed in the TQt3 to avoid collisions with >> Qt4 ones. > > This probably should be elevated to a bug report, probably Blocker status. I have run into this problem too and is one of the several conflicts I have mentioned with KDE4/Qt4. > Filling it now. > My short term solution is not to install (T)Qt3 to /usr, where Qt4 more than likely is installed from the distro maintainers. That straightforward solution avoids most of the problems because /opt/trinity/bin will have the higher priority in $PATH. However, that does not mean no problems. Any Qt4 app that is run from within the Trinity environment and looks for those executables will find the (T)Qt3 version first rather than the Qt4 versions. > I install qt under /opt, so the executables are not overwritten. But In arch I need to append the /opt/qt to the path after original path, so the qt4 version will always get executed instead of qt3 one. > Additionally, my build script has a snippet that when (T)Qt3 is installed to /usr, then I create sym linked file names in /usr/bin. I append the sym linked names with "-tqt3" or "-qt3" suffixes as appropriate. > I do the same thing in Arch PKGBUILDs. > Clunky. > > We do need a solid long-term solution. :) > > Darrell > 2012/2/1 Calvin Morrison <mutantturkey@...>: > > Ubuntu nicely works around this by renaming the applications to something > like > > moc-qt3 designer-qt3 etc Could you check the executables? Are they renamed, or is this only a package naming / symlinks like I do?