[Kde-imaging] problems with finding correct exiv2
fabien.ubuntu at gmail.com
Wed May 16 10:28:57 CEST 2007
I perfectly remember this problem. There were already a thread about
this in digikam-users.
Check here :
The code for the PKG_CONFIG_PATH test is part of kde-common :
(at the end of the file)
dnl A small extension to PKG_CHECK_MODULES (defined in pkg.m4.in)
dnl which allows to search for libs that get installed into the KDE prefix.
dnl Syntax: KDE_PKG_CHECK_MODULES(KSTUFF, libkexif >= 0.2 glib = 1.3.4,
dnl defines KSTUFF_LIBS, KSTUFF_CFLAGS, see pkg-config man page
dnl also defines KSTUFF_PKG_ERRORS on error
if test "$prefix" != "$kde_libs_prefix"; then
I also think it would be better to reverse the order, but I remember
that could lead to some side effects : test was ok with pkg-config, but
the Makefile didn't use the defined path first when linking.
So, sometime you can have a case where everything looks good, but
linking is done using the old version. I let you imagine how bad it
could be :)
More tests must be done before doing that...
Arnd Baecker wrote:
>>When trying to compile kipiplugins, obtained via
>> svn co svn://anonsvn.kde.org/home/kde/trunk/extragear/libs
>> make -f Makefile.cvs
>> ./configure --prefix=$DIGIKAMDEST \
>> --with-extra-includes=$DIGIKAMDEST/include \
>>the wrong exiv2 is found:
>>I have a 0.10 in /usr/
>>and a self-compiled (0.14) in $DIGIKAMDEST, but
>>only the first is found.
>>Fiddling around with the configure script, it
>>turned out that changing the order of
>>the definitions of PKG_CONFIG_PATH inside the script to
>>did solve the problem for me.
>>Is there a better solution?
>>(and, if not, maybe the above ordering should be the default
>>so that alternative configurations are used instead
>>of the usual ones?)
More information about the Kde-imaging