Version: 2.1.5 (using KDE KDE 3.1.1a) Installed from: Mandrake RPMs OS: Linux It looks like there's a problem building KDevelop that renders it useless when installed from distro rpm's. This occurs in several linux distros (at least Redhat and Mandrake... do a Usenet search for 'kdevelop qt-mt'), so I'm reporting it here in the hope it can be fixed so it won't recur in the future. Work-arounds have been proposed but they involve compiling and linking KDevelop. Create a new project. In wizard, leave everything as default, except to specify a project name. Fails with following errors: ----------------------------------------------------- shell-init: could not get current directory: getcwd: cannot access parent directories: No such file or directory shell-init: could not get current directory: getcwd: cannot access parent directories: No such file or directory configure: error: Qt (>= Qt 3.0.3) (library qt-mt) not found. Please check your installation! For more details about this problem, look at the end of config.log. Make sure that you have compiled Qt with thread support! warning: HermesView inherits unknown class 'QWidget' warning: HermesDoc inherits unknown class 'QObject' warning: HermesApp inherits unknown class 'KMainWindow' ----------------------------------------------------- I have checked: /usr/lib/qt3/lib contains libqt-mt.so.3.1.2 and a link to it named libqt-mt.so, and /usr/lib/qt3/lib is listed in /etc/ld.so.conf. From distro rpms, I had previously upgraded my KDE to 3.1.3a. Since finding this problem, I have upgraded KDevelop to build 2.1.5-5mdk, to no avail.
More info: Work-around: Allow project creation to fail, then under "Project->Options...->Compiler Options->Linker Flags", in Additional flags, put -L/usr/X11R6/lib -L/usr/lib/qt3 -lGL -lXmu -lXrender -lXft -lXext -lX11 -lSM -lICE -lXt Got idea from config.log file. It seemed to indicate the problem wasn't really with finding qt3, or with the qt-mt library, but with finding libraries referenced by qt-mt. I think I've seen this before. Maybe has something to do with new gcc? ---------------------------------------------------------------- configure:6881: rm -rf SunWS_cache; c++ -o conftest -O2 -O0 -g3 -Wall -fno-excep tions -fno-check-new -I/usr/lib/qt3/include -I/usr/X11R6/include -DQT_THREAD_SU PPORT -D_REENTRANT -L/usr/lib/qt3/lib -L/usr/X11R6/lib conftest.C -lqt-mt - lpng -lz -lm -ljpeg -ldl -lXext -lX11 -lSM -lICE -lresolv -lpthread 1>&5 /usr/bin/ld: warning: libGL.so.1, needed by /usr/lib/qt3/lib/libqt-mt.so, not fo und (try using -rpath or -rpath-link) /usr/bin/ld: warning: libXmu.so.6, needed by /usr/lib/qt3/lib/libqt-mt.so, not f ound (try using -rpath or -rpath-link) /usr/bin/ld: warning: libXrender.so.1, needed by /usr/lib/qt3/lib/libqt-mt.so, n ot found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libXft.so.2, needed by /usr/lib/qt3/lib/libqt-mt.so, not f ound (try using -rpath or -rpath-link) /usr/lib/qt3/lib/libqt-mt.so: undefined reference to `glXQueryServerString' /usr/lib/qt3/lib/libqt-mt.so: undefined reference to `glColor3ub' /usr/lib/qt3/lib/libqt-mt.so: undefined reference to `XftDrawRect' /usr/lib/qt3/lib/libqt-mt.so: undefined reference to `glIndexi' /usr/lib/qt3/lib/libqt-mt.so: undefined reference to `glPopAttrib' ---------------------------------------------------------------- ...etc.
-L/usr/X11R6/lib -lXmu -lXrender -lXft -lXext -lX11 -lSM -lICE -lXt works as well
This does not appear to be a KDE/KDevelop bug at all. Please report to the distributions' bug tracking systems. Besides, KDevelop 2.x is no longer being developed. Please upgrade.
KDevelop 2 is being distributed. There are lots of people reporting the same problem on the net. Surely a bugfix could be released. If you feel that this isn't your problem, please tell me whose problem it is, so I can report it to them. The bug in KDevelop is that it reports that libqt-mt cannot be found, although in fact it has found that library. In fact, the test it runs is to attempt to link it with gcc, and this test fails because it has failed to link in other libraries needed by libqt-mt. As far as upgrading is concerned, I'll wait until my distro releases an rpm, but thanks for the advice!
I'm not part of the KDevelop team, so I won't close this bug again. But I'm sure they have already closed bugs with messages "KDevelop 2.x is no longer developed and no further patches to it will be released". As for your problem, does it only happen with installed RPM packages? If you install from source it doesn't happen? If that's the case, then it's most surely a packaging bug (= report to your distribution), not a KDE bug.
Mandrake updated the compiler and the auto* tools to versions that are incompatible with KDevelop 2.x. KDevelop 2.x is a KDE 2.x product designed to develop KDE 2.x apps and has been patched to also support KDE 3.x. Please understand that the development team is too small to support two branches _and_ several distros, especially when they put the newest stuff on the DVDs without checking that the old stuff still works. Check KDevelop 3.x, if you don't like it, you can create a new project with it and import it as custom project in KDevelop 2.x, that should work. At least SuSE has some entries in their knowledge base how to make KDevelop work with SuSE 8.x, you might want to check if your distro has something similar.
OK, I'm convinced this would be more effectively treated as a bug with version choices in package dependencies than with KDevelop itself, so I'll leave it closed. Mandrake knew about this well before the latest release. I have to think they could have done something. http://qa.mandrakesoft.com/show_bug.cgi?id=1751 However, it isn't just a Mandrake issue Red Hat people are reporting the same problem. This isn't a very good way to handle bug reports on different branches. Instead of pooh-poohing, then closing, reports about a (widely-distributed) branch on the grounds that the branch no longer has your interest, it would be better to have two branches for bug reports, with an automatic message for bug reporters to the effect that a branch isn't being actively developed. That way, valid reports of problems that have not been resolved won't get marked RESOLVED INVALID.