Version: (using KDE 4.1.1) OS: Linux Installed from: I Don't Know Steps to reproduce: 1. Install old (KDE3) versions of libkipi, libkexiv2, libkdcraw into /usr 2. Setup KDE 4.1.1 for example in /usr/kde/4.1/ 3. Try to compile for example digiKam 0.10-betaX or gwenview 4.1.1, exporting PKG_CONFIG_PATH=/usr/kde/4.1/lib/pkgconfig 4. pkg-config returns correct lib paths (/usr/kde/4.1/lib/libkipi.so) in FindK{dcraw,ipi,exiv2}.cmake, but cmake calls like "find_library(KIPI_LIBRARIES NAMES kipi PATHS ${KDE4_LIB_DIR} ${_KIPILinkDir})" do search system default folders FIRST [1], resulting in incorrect libs returned (/usr/libkipi.so). The solution is to call find_* cmake commands with NO_DEFAULT_PATH first, and fallback to system paths. [1] Will attach patch, should be applied to both trunk and 4.1 branch. Matěj Laitl. [1] http://www.cmake.org/cmake/help/cmake-2.6.html#command:find_library
Created attachment 27511 [details] kdelibs-4.1.1-cmake-modules.patch
This seems to be hangind indefinitely, resolving as REMIND.
If the problem's still valid, I think it makes sense to leave the bug open.
Right then, I don't know who should I bug - perhaps you know and can do it?
Filing a ReviewBoard request to the "buildsystem" group and optionally poking people on the kde-buildsystem mailing list is usually the fastest way to get this sort of thing reviewed.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Right, this has been reported for a very old version.