Re: Fwd: Re: Exiv2 library missing???

Alle 13:22, giovedì 7 dicembre 2006, hai scritto:

> Angelo,
>
> And another Exiv2 thread from [hidden email] ML...
>
> Gilles
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: [Digikam-users] Exiv2 library missing???
> Date: Thursday 07 December 2006 13:26
> From: Thorsten Schnebeck <[hidden email]>
> To: digiKam - Digital Photo Management for the masses <[hidden email]>
>
> On Thursday, December 7, 2006 12:54:47 PM Fabien wrote:
> > Hi,
> >
> > Thorsten Schnebeck wrote:
> > > On Thursday, December 7, 2006 11:11:23 AM Daniel Bauer wrote:
> > >>using PKGCONFIGFOUND="no" makes configure complain about other missing
> > >>parts:
> > >
> > > yes, of course
> > >
> > >>-- Exiv2 library found............ YES
> > >>Now that it finds Exiv2 it doesn't find sqlite and libkipi anymore...
> > >
> > > I want only a simple test if my analyse fits on your system - and this
> > > seems to be true.
> > >
> > > You have to options:
> > > 1) Try to convince the kipi-devels that the current kipi configure-checks
> > > is bad style

To convince us, they should propose something better and they should

argue why it's bad style, or am I wrong?
> >
> > I'm not sure they are wrong :) Maybe KDE_PKG_CHECK_MODULES could be
> > replaced by PKG_CHECK_MODULES in graphics/digikam/configure.in.in
> > <http://websvn.kde.org/trunk/extragear/graphics/digikam/configure.in.in?rev
> >=609246&view=markup>
>
> I dont understand why digikam uses pgk-config at all when it first check for
> exiv2-config. So digikam could simply use exiv2-config --version for the
> version check.
Well which is the difference, since we use it for libkipi (even if it's KDE_PKG_CHECK_MODULES)
and for libgpod? I believe a common way it's easier to maintain. Just decide which, and I believe
once it's ok for the most, no one complains.

Angelo

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Fabien-5]

Hi,

Angelo Naselli wrote:
> Alle 13:22, giovedì 7 dicembre 2006, hai scritto:

>>>>You have to options:
>>>>1) Try to convince the kipi-devels that the current kipi configure-checks
>>>>is bad style
>
> To convince us, they should propose something better and they should
> argue why it's bad style, or am I wrong?

I think you're right :)

>>>I'm not sure they are wrong :) Maybe KDE_PKG_CHECK_MODULES could be
>>>replaced by PKG_CHECK_MODULES in graphics/digikam/configure.in.in
>>><http://websvn.kde.org/trunk/extragear/graphics/digikam/configure.in.in?rev
>>>=609246&view=markup>
>>
>>I dont understand why digikam uses pgk-config at all when it first check for
>>exiv2-config. So digikam could simply use exiv2-config --version for the
>>version check.
>
> Well which is the difference, since we use it for libkipi (even if it's KDE_PKG_CHECK_MODULES)
> and for libgpod? I believe a common way it's easier to maintain. Just decide which, and I believe
> once it's ok for the most, no one complains.

I think using pkg-config is the right way to do it. I did some tests
yesterday with PKG_CHECK_MODULES instead of KDE_PKG_CHECK_MODULES, but
it seems to lead to other issues (bad order of -L and -I which makes the
compiler and the linker use older version of libs even if the check was
successful). So, maybe it's more consistent to use KDE_PKG_CHECK_MODULES...
I need to investigate a bit more about that. I will give more details later.


But, in any case, it's true that there's something confusing in the
configure script :
- first, EXIV2_CFLAGS and LIB_EXIV2 are defined :

EXIV2_CFLAGS="`$EXIV2_CONFIG --cflags`"
LIB_EXIV2="`$EXIV2_CONFIG --libs`"

- then, EXIV2_CFLAGS is redefined and a new EXIV2_LIBS is defined (and
not LIB_EXIV2) :

EXIV2_CFLAGS=`$PKG_CONFIG --cflags "exiv2 >= 0.12"`
EXIV2_LIBS=`$PKG_CONFIG --libs "exiv2 >= 0.12"`

I don't know yet which one is the right one, but I guess we shouldn't
have both LIB_EXIV2 and EXIV2_LIBS at the same time...


--
Fabien

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Thursday, December 7, 2006 02:50:36 PM Angelo Naselli wrote:

> > > > You have to options:
> > > > 1) Try to convince the kipi-devels that the current kipi
> > > > configure-checks is bad style
>
> To convince us, they should propose something better and they should
> argue why it's bad style, or am I wrong?

Hi Angelo,

the discussion was a "little" bit longer, so you don't have enough information
so far:

The aim is to install a test version of digikam and all of its components into
a separate directory. That way you have a stable version and a test version.

Problem is to install two versions of exiv2-lib. Here are some side effects.
dikikam checks for exiv2 by searching for exiv-config and check its version
by using pkg-config.

So if you want to differentiate two version of libexiv2 you need to adjust
your  PKG_CONFIG_PATH env variable.

But kipi-check destroys/adjusts your PKG_CONFIG_PATH:

> #------------------------------------------------------------------
> # KIPI support (KDE Image Plugin Interface)
> #------------------------------------------------------------------
>
> if test "$PKGCONFIGFOUND" = "yes" ; then
>    # check for libkipi
>    have_libkipi=no
>
>    PKG_CONFIG_PATH="$prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_PATH"
>    if test "$prefix" != "$kde_libs_prefix"; then
>        PKG_CONFIG_PATH="$kde_libs_prefix/lib${kdelibsuff}/pkgconfig:
> $PKG_CONFIG_PATH"
>    fi
>    export PKG_CONFIG_PATH

If your stable version of libexiv2 stays in $prefix/lib${kdelibsuff} you can
not use another lib version cause KIPI support overwrites PKG_CONFIG_PATH.

I called this bad style cause when studying other configure check I often saw
this style:

pkgconfig_save=$PKG_CONFIG_PATH
PKG_CONFIG_PATH=(what ever I need)
(do some tests)
PKG_CONFIG_PATH=$pkgconfig_save

But KIPI support exports this changed environment variable.

Solutions to solve this problem:

1) a save redefinition like:
PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$prefix/lib${kdelibsuff}/pkgconfig"

2) digikam uses exiv2-config and not pkg-config

3) pkgconfig_save method without exporting

Bye

  Thorsten


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Alle 10:14, venerdì 8 dicembre 2006, Thorsten Schnebeck ha scritto:

> On Thursday, December 7, 2006 02:50:36 PM Angelo Naselli wrote:
>
> > > > > You have to options:
> > > > > 1) Try to convince the kipi-devels that the current kipi
> > > > > configure-checks is bad style
> >
> > To convince us, they should propose something better and they should
> > argue why it's bad style, or am I wrong?
>
> Hi Angelo,
>
> the discussion was a "little" bit longer, so you don't have enough information
> so far:
>
> The aim is to install a test version of digikam and all of its components into
> a separate directory. That way you have a stable version and a test version.

I see, but of course that is a "developing" issue.

I maybe wrong and I'm going to check it better because a lot of autotools stuff
are often reworked by kde admins one, but there is a standard way to "influence"
configure script behavior, e.g. changing environment variables.
>
> Problem is to install two versions of exiv2-lib. Here are some side effects.
> dikikam checks for exiv2 by searching for exiv-config and check its version
> by using pkg-config.
>
> So if you want to differentiate two version of libexiv2 you need to adjust
> your  PKG_CONFIG_PATH env variable.
And that imo should be the right way to.
>
> But kipi-check destroys/adjusts your PKG_CONFIG_PATH:
hmm I'll check it, if so the wrong behavior is there, not in the exiv2 test.
>
> > #------------------------------------------------------------------
> > # KIPI support (KDE Image Plugin Interface)
> > #------------------------------------------------------------------
> >
> > if test "$PKGCONFIGFOUND" = "yes" ; then
hmm if I'm not wrong that is the way it's used by digikam, amarok and kipi & co.
to be honest I don't like adding a way to overwrite standard way though.
> >    # check for libkipi
> >    have_libkipi=no
> >
> >    PKG_CONFIG_PATH="$prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_PATH"
> >    if test "$prefix" != "$kde_libs_prefix"; then
> >        PKG_CONFIG_PATH="$kde_libs_prefix/lib${kdelibsuff}/pkgconfig:
> > $PKG_CONFIG_PATH"
> >    fi
> >    export PKG_CONFIG_PATH
hmm reading the above code it seems not to override anything, it simply
add as first entry the $prefix/lib... path. Again if I'm not wrong we're
talking about configure script so --prefix change the install path and
$prefix variable. So what you saw it's a way to say to configure to find
first pkgconfig directory in your installation directory and after that
int the standard one.
Let's say you're using ./configure --prefix=$HOME/KDE/INSTALL,
PKG_CONFIG_PATH will be "/home/yourhome/KDE/INSTALL/lib/pkgconfig:old_path"
So if you use a PKG_CONFIG_PATH=/my/optional/installation/lib/pkgconfig:/usr/lib/pkgconfig
and run configure again you should change the beahvior as you like.
>
> If your stable version of libexiv2 stays in $prefix/lib${kdelibsuff} you can
> not use another lib version cause KIPI support overwrites PKG_CONFIG_PATH.
I don't get it sorry. If I'm not wrong libexiv can't be compiled togheter
kipi & co or digikam or... It's a different package/project. So you should use
./configure --prefix=/my/optional/installation/ for exiv and cahnge your PKG_CONFIG_FILE
variable should work for other projects. Am I missing something?
>
> I called this bad style cause when studying other configure check I often saw
> this style:
>
> pkgconfig_save=$PKG_CONFIG_PATH
> PKG_CONFIG_PATH=(what ever I need)
> (do some tests)
> PKG_CONFIG_PATH=$pkgconfig_save
We can add some more tests, but why? IMO the standard way should be enough.
If you use LD_LIBRARY_PATH you change the use of dinamic libraries right?
so using PKG_CONFIG_PATH you should reach your aim. If that does not work
then I agree there's a problem and we must fix it. But I've just had a
report from a kipi-plugins user that using PKG_CONFIG_PATH  and LD_LIBRARY_PATH
makes the trick, so I'm not sure it doesn't.
 
> But KIPI support exports this changed environment variable.
>
> Solutions to solve this problem:
>
> 1) a save redefinition like:
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$prefix/lib${kdelibsuff}/pkgconfig"

> 2) digikam uses exiv2-config and not pkg-config
from digikam configure.in.in
 #------------------------------------------------------------------
# Check for Exiv2 library
#------------------------------------------------------------------

have_exiv2='no'
AC_PATH_PROG(EXIV2_CONFIG,exiv2-config)
if test -n "${EXIV2_CONFIG}"; then
  EXIV2_CFLAGS="`$EXIV2_CONFIG --cflags`"
  AC_SUBST(EXIV2_CFLAGS)
  LIB_EXIV2="`$EXIV2_CONFIG --libs`"
  AC_SUBST(LIB_EXIV2)
  PKG_CHECK_MODULES(EXIV2, exiv2 >= 0.12, have_exiv2=yes,have_exiv2=no)
fi

from kipi-plugins one
#------------------------------------------------------------------
# Check for Exiv2 library
#------------------------------------------------------------------
have_exiv2='no'
AC_PATH_PROG(EXIV2_CONFIG,exiv2-config)
if test -n "${EXIV2_CONFIG}"; then
  EXIV2_CFLAGS="`$EXIV2_CONFIG --cflags`"
  AC_SUBST(EXIV2_CFLAGS)
  LIB_EXIV2="`$EXIV2_CONFIG --libs`"
  AC_SUBST(LIB_EXIV2)
  PKG_CHECK_MODULES(EXIV2, exiv2 >= 0.12, have_exiv2=yes,have_exiv2=no)
fi

I don't see any difference. Before using exiv2-config we used a
test on a file (hpp) IIRC, that was not very good imo.
> 3) pkgconfig_save method without exporting
Try the solution i proposed and tell me if it's wrong and we'll
see where and if we have to change anything.


Angelo

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Fabien-5]

Fabien wrote:

>>Well which is the difference, since we use it for libkipi (even if it's KDE_PKG_CHECK_MODULES)
>>and for libgpod? I believe a common way it's easier to maintain. Just decide which, and I believe
>>once it's ok for the most, no one complains.
>
>
> I think using pkg-config is the right way to do it. I did some tests
> yesterday with PKG_CHECK_MODULES instead of KDE_PKG_CHECK_MODULES, but
> it seems to lead to other issues (bad order of -L and -I which makes the
> compiler and the linker use older version of libs even if the check was
> successful). So, maybe it's more consistent to use KDE_PKG_CHECK_MODULES...
> I need to investigate a bit more about that. I will give more details later.

Well, I end up without a proper solution. The configure script is more
than 47'000 lines of code :(

So, this is what I saw :

The configure script generates Makefile that contains (in my setup) :

all_includes = -I/usr/include/kde -I/usr/share/qt3/include -I.
-I/localhome/fabien/myopt/include
all_libraries = -L/usr/share/qt3/lib -L/usr/lib
-L/localhome/fabien/myopt/lib

The paths with /localhome/fabien are the one I put by using
--with-extra-includes=$DIGIKAMDEST/include
--with-extra-libs=$DIGIKAMDEST/lib

Here, the problem is that /usr/lib is used before my local lib
directory, so if there's already exiv2 libs in this path, the linker
will use the old lib.
I discovered that the first time because there's an unknown method in
the old lib (I did some tests by installing 0.11 in /usr).

<<
In function `Digikam::DMetadata::clearExif()':
dmetadata.cpp:(.text+0xbdc6): undefined reference to
`Exiv2::ExifData::clear()'
 >>

If somebody can find where (and why) the local paths are not used first,
it would be great :)

Trying to allow the compilation of digikam using local libs albeit
standard libs are present will alway lead to bugs and troubles.
So, maybe it's better like that (ie system path first, before local
paths). This will prevent bug reports of people mixing different
*developpment files* of exiv2.

After all, there are not many reasons to have multiple developpment
headers of the same lib in different versions :)

--
Fabien

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Fabien-5]

Hi,

Angelo Naselli wrote:
> Alle 10:14, venerdì 8 dicembre 2006, Thorsten Schnebeck ha scritto:
 >
 > [...]
>
> And that imo should be the right way to.
>
>>But kipi-check destroys/adjusts your PKG_CONFIG_PATH:
>
> hmm I'll check it, if so the wrong behavior is there, not in the exiv2 test.

Right.

>>>#------------------------------------------------------------------
>>># KIPI support (KDE Image Plugin Interface)
>>>#------------------------------------------------------------------
>>>
>>>if test "$PKGCONFIGFOUND" = "yes" ; then
>
> hmm if I'm not wrong that is the way it's used by digikam, amarok and kipi & co.
> to be honest I don't like adding a way to overwrite standard way though.
>
>>>   # check for libkipi
>>>   have_libkipi=no
>>>
>>>   PKG_CONFIG_PATH="$prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_PATH"
>>>   if test "$prefix" != "$kde_libs_prefix"; then
>>>       PKG_CONFIG_PATH="$kde_libs_prefix/lib${kdelibsuff}/pkgconfig:
>>>$PKG_CONFIG_PATH"
>>>   fi
>>>   export PKG_CONFIG_PATH
>
> hmm reading the above code it seems not to override anything, it simply
> add as first entry the $prefix/lib... path. Again if I'm not wrong we're
> talking about configure script so --prefix change the install path and
> $prefix variable. So what you saw it's a way to say to configure to find
> first pkgconfig directory in your installation directory and after that
> int the standard one.
> Let's say you're using ./configure --prefix=$HOME/KDE/INSTALL,
> PKG_CONFIG_PATH will be "/home/yourhome/KDE/INSTALL/lib/pkgconfig:old_path"
> So if you use a PKG_CONFIG_PATH=/my/optional/installation/lib/pkgconfig:/usr/lib/pkgconfig
> and run configure again you should change the beahvior as you like.

The problem is not on the 1st line that even permit us to not have to
define manually PKG_CONFIG_PATH.
It's on the 3rd line that add
$kde_libs_prefix/lib${kdelibsuff}/pkgconfig before the 1st path.

>>If your stable version of libexiv2 stays in $prefix/lib${kdelibsuff} you can
>>not use another lib version cause KIPI support overwrites PKG_CONFIG_PATH.
>
> I don't get it sorry. If I'm not wrong libexiv can't be compiled togheter
> kipi & co or digikam or... It's a different package/project. So you should use
> ./configure --prefix=/my/optional/installation/ for exiv and cahnge your PKG_CONFIG_FILE
> variable should work for other projects. Am I missing something?

This works perfectly except if exiv2 is installed with developpment
headers in the default previx (usually /usr/lib). In that case, the
local lib won't be used...
But, this could be solved easily in the admin/acinclude.m4.in

I tried, but it's not enough because -L/usr/lib is used before
-L/my/local/path when linking, so it's not enough (cf my previous email).

My opinion is that's not a problem directly related to digikam, but more
to KDE. But, maybe it's by design.

--
Fabien

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users