compile problems for digikam

[Arnd Baecker]

Hi,

it seems that people really struggle hard installing digikam from svn.
This is, from my point of view, a substantial problem,
preventing possible contributors from even getting started.
It also prevents people from trying out current svn to
see if bugs got fixed; many just wait until
packages exist for their system ...

Most likely, there are many users which tried, failed,
and never reported back to us!

Needless to say, that such problems have wasted
already several hours, both on the users side and
on the side of the digikam team .... ;-)

Gilles, Marcel and everyone else:
is there something which can be done to improve the situation?

The main problems which seem to occur are
(Not that the following is not written with any understanding/knowledge,
but just an attempt at a summary):
A) Different libexiv2 on the system seem to cause problems.
   I just don't understand why?
   If they are at separate places, and the paths are
   set correctly, this should do no harm at all.
B) The same with kexiv2, kdcraw, it seems
   (not sure about libkipi, kipi-plugins)?
C) kioslave might not always be updated
   (i.e. kdeinit or kbuildsycoca  might be needed)

Is it possible to solve any of these issues?

One simple diagnostic tool might be to print out
the compile date  and time + svn revision + version
of the pieces involved?
(Would this be possible?)

Are there better approaches?

Best, Arnd


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

[Gilles Caulier-4]

2008/4/26 Arnd Baecker <[hidden email]>:

> Hi,
>
>  it seems that people really struggle hard installing digikam from svn.
>  This is, from my point of view, a substantial problem,
>  preventing possible contributors from even getting started.
>  It also prevents people from trying out current svn to
>  see if bugs got fixed; many just wait until
>  packages exist for their system ...
>
>  Most likely, there are many users which tried, failed,
>  and never reported back to us!
>
>  Needless to say, that such problems have wasted
>  already several hours, both on the users side and
>  on the side of the digikam team .... ;-)
>
>  Gilles, Marcel and everyone else:
>  is there something which can be done to improve the situation?
>
>  The main problems which seem to occur are
>  (Not that the following is not written with any understanding/knowledge,
>  but just an attempt at a summary):
>  A) Different libexiv2 on the system seem to cause problems.
>    I just don't understand why?
>    If they are at separate places, and the paths are
>    set correctly, this should do no harm at all.

Exiv2 0.14 has switched to libtool's -version-info versioning system.

I recommend to always use Exiv2 >= 0.14, else mixing a recent release
and a older one < 0.14 will introduce dysfunction.

It still other way to fix in Exiv2, to improve binary compatibility
for ex, using 'd' private internal classes for all private member. But
it's a huge work to do.


 >  B) The same with kexiv2, kdcraw, it seems
>    (not sure about libkipi, kipi-plugins)?

There is no reason for kipi-plugins. it's not a shared lib.

For kexiv2, kdcraw, kipi, it certainly an auto-tools issue.

>  C) kioslave might not always be updated
>    (i.e. kdeinit or kbuildsycoca  might be needed)
>

Ah the kio-slaves. I'm currently fight against KDE4 under Mandriva
2008.1. Since i have updated my system, when i start digiKam 0.10.0
under KDE3, all kioslave are not able to find libdigikam.la and do not
start.

It's certainly a wrong env. settings.

It's the same for kioslave from digiKam 0.9.x

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

Dnia Saturday 26 of April 2008, Arnd Baecker napisał:

> Gilles, Marcel and everyone else:
> is there something which can be done to improve the situation?
>
> The main problems which seem to occur are
> (Not that the following is not written with any understanding/knowledge,
> but just an attempt at a summary):
> A) Different libexiv2 on the system seem to cause problems.
>    I just don't understand why?
>    If they are at separate places, and the paths are
>    set correctly, this should do no harm at all.

> B) The same with kexiv2, kdcraw, it seems
>    (not sure about libkipi, kipi-plugins)?

Better checking for version of kexiv2 (and exiv2 itself)?
Configure scrips are checking only for regular version number eg. 0.16
while all this pieces are very actively developed and often newer
version of digiKam svn require specific svn versions of these two
elements - especially kexiv2.

AFAIK there is no direct dependency on libkipi. But libkipi and
kipi-plugins also depend on kdcraw and (k)exiv2.

> C) kioslave might not always be updated
>    (i.e. kdeinit or kbuildsycoca  might be needed)

Never had any problems with that.

> Is it possible to solve any of these issues?
>
> One simple diagnostic tool might be to print out
> the compile date  and time + svn revision + version
> of the pieces involved?
> (Would this be possible?)
>
> Are there better approaches?

More monolithic approach? Some svn "symlinks" which will cause automatic
update of libraries from extragear/libs ? KOffice was using that trick
to use kdgantt library from kdepim. Also admin directory in all KDE
modules is updated that way.

m.

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

On Saturday, 26. April 2008, Gilles Caulier wrote:

> 2008/4/26 Arnd Baecker <[hidden email]>:
> > Hi,
> >
> >  it seems that people really struggle hard installing digikam from svn.
> >  This is, from my point of view, a substantial problem,
> >  preventing possible contributors from even getting started.
> >  It also prevents people from trying out current svn to
> >  see if bugs got fixed; many just wait until
> >  packages exist for their system ...
> >
> >  Most likely, there are many users which tried, failed,
> >  and never reported back to us!
> >
> >  Needless to say, that such problems have wasted
> >  already several hours, both on the users side and
> >  on the side of the digikam team .... ;-)
> >
> >  Gilles, Marcel and everyone else:
> >  is there something which can be done to improve the situation?
> >
> >  The main problems which seem to occur are
> >  (Not that the following is not written with any understanding/knowledge,
> >  but just an attempt at a summary):
> >  A) Different libexiv2 on the system seem to cause problems.
> >    I just don't understand why?
> >    If they are at separate places, and the paths are
> >    set correctly, this should do no harm at all.
>
> Exiv2 0.14 has switched to libtool's -version-info versioning system.
>
> I recommend to always use Exiv2 >= 0.14, else mixing a recent release
> and a older one < 0.14 will introduce dysfunction.
>
> It still other way to fix in Exiv2, to improve binary compatibility
> for ex, using 'd' private internal classes for all private member. But
> it's a huge work to do.

As explained below it really worth not breaking ABI ;)


>  >  B) The same with kexiv2, kdcraw, it seems
> >    (not sure about libkipi, kipi-plugins)?
>
> There is no reason for kipi-plugins. it's not a shared lib.

I disagree ;)  In my, maybe a bit outdated experience, in most problem
with library mismatch crashes kipi-plugins are involed.

The problem if kipi-plugins uses lib<foo>.so.<M>  all apps using
kipi-plugins: digikam, gwenview, kphotoalbum ...  should be linked
against same version <M>.  As soon as an apps uses a different version,
e.g, <N>,  two not ABI compatible version of a library are loaded
into memory ==> crash.

As digikam svn relies very often of very recent, often svn version
of libaries. So new libs with changed API are used by digikam from svn.
==> trouble for the uninitialed ;)

> For kexiv2, kdcraw, kipi, it certainly an auto-tools issue.
>
> >  C) kioslave might not always be updated
> >    (i.e. kdeinit or kbuildsycoca  might be needed)


Yeah, right.  But I have to admin I never really understood
why.   E.g. for .desktop files, KDED monitors the locations
an updates the syscocadb.  As this problem happens also with
other KDE apps it would be nice to understand what goes wrong.

Achim

>
> Ah the kio-slaves. I'm currently fight against KDE4 under Mandriva
> 2008.1. Since i have updated my system, when i start digiKam 0.10.0
> under KDE3, all kioslave are not able to find libdigikam.la and do not
> start.
>
> It's certainly a wrong env. settings.
>
> It's the same for kioslave from digiKam 0.9.x
>
> Gilles
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

--
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [hidden email]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

Am Samstag 26 April 2008 schrieb Arnd Baecker:

> Hi,
>
> it seems that people really struggle hard installing digikam from svn.
> This is, from my point of view, a substantial problem,
> preventing possible contributors from even getting started.
> It also prevents people from trying out current svn to
> see if bugs got fixed; many just wait until
> packages exist for their system ...
>
> Most likely, there are many users which tried, failed,
> and never reported back to us!
>
> Needless to say, that such problems have wasted
> already several hours, both on the users side and
> on the side of the digikam team .... ;-)
>
> Gilles, Marcel and everyone else:
> is there something which can be done to improve the situation?
>
> The main problems which seem to occur are
> (Not that the following is not written with any understanding/knowledge,
> but just an attempt at a summary):
> A) Different libexiv2 on the system seem to cause problems.
>    I just don't understand why?
>    If they are at separate places, and the paths are
>    set correctly, this should do no harm at all.

There is always a hundred reasons why compiler search paths, linker paths, and
the dynamic linker may look at different places. It's so difficult to fix
even if you sit in front of the machine, so we usually take the uninstall +
reinstall path. Bad if there are leftovers somewhere.

> B) The same with kexiv2, kdcraw, it seems
>    (not sure about libkipi, kipi-plugins)?
> C) kioslave might not always be updated
>    (i.e. kdeinit or kbuildsycoca  might be needed)

For kioslaves (looking at the problem Andi Clemens had):
First thing is that a make install is definitely needed.
After all still running instances of ioslaves have shut down, which they
usually do after a short time, the new libraries take effect.
But output is always directed to the console of kdeinit. This means in my KDE3
environment, this is the file ~/.xsession-errors. If you restart kdeinit from
a console, it's your console.


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

[Gilles Caulier-4]

2008/4/26 Gilles Caulier <[hidden email]>:

> 2008/4/26 Arnd Baecker <[hidden email]>:
>
> > Hi,
>  >
>  >  it seems that people really struggle hard installing digikam from svn.
>  >  This is, from my point of view, a substantial problem,
>  >  preventing possible contributors from even getting started.
>  >  It also prevents people from trying out current svn to
>  >  see if bugs got fixed; many just wait until
>  >  packages exist for their system ...
>  >
>  >  Most likely, there are many users which tried, failed,
>  >  and never reported back to us!
>  >
>  >  Needless to say, that such problems have wasted
>  >  already several hours, both on the users side and
>  >  on the side of the digikam team .... ;-)
>  >
>  >  Gilles, Marcel and everyone else:
>  >  is there something which can be done to improve the situation?
>  >
>  >  The main problems which seem to occur are
>  >  (Not that the following is not written with any understanding/knowledge,
>  >  but just an attempt at a summary):
>  >  A) Different libexiv2 on the system seem to cause problems.
>  >    I just don't understand why?
>  >    If they are at separate places, and the paths are
>  >    set correctly, this should do no harm at all.
>
>  Exiv2 0.14 has switched to libtool's -version-info versioning system.
>
>  I recommend to always use Exiv2 >= 0.14, else mixing a recent release
>  and a older one < 0.14 will introduce dysfunction.
>
>  It still other way to fix in Exiv2, to improve binary compatibility
>  for ex, using 'd' private internal classes for all private member. But
>  it's a huge work to do.
>
>
>
>   >  B) The same with kexiv2, kdcraw, it seems
>  >    (not sure about libkipi, kipi-plugins)?
>
>  There is no reason for kipi-plugins. it's not a shared lib.
>
>  For kexiv2, kdcraw, kipi, it certainly an auto-tools issue.
>
>
>  >  C) kioslave might not always be updated
>  >    (i.e. kdeinit or kbuildsycoca  might be needed)
>  >
>
>  Ah the kio-slaves. I'm currently fight against KDE4 under Mandriva
>  2008.1. Since i have updated my system, when i start digiKam 0.10.0
>  under KDE3, all kioslave are not able to find libdigikam.la and do not
>  start.
>
>  It's certainly a wrong env. settings.
>
>  It's the same for kioslave from digiKam 0.9.x
>
>  Gilles
>

Arnd,

For KDE4 with Mandriva 2008.1, there is a script named "k4" which
initialize all env. bash variable to be able to run a KDE4 application
under KDE3. Look the new env created :

[gilles@localhost ~]$ export > k1.txt
[gilles@localhost ~]$ k4
[gilles@localhost ~]$ export > k2.txt
[gilles@localhost ~]$ diff k1.txt k2.txt
2a3
> declare -x DBUSDIR="/opt/kde4"
18a20,24
> declare -x KDEDIR="/opt/kde4"
> declare -x KDEDIRS="/opt/kde4"
> declare -x KDEHOME="/home/gilles/.kde4"
> declare -x KDETMP="/home/gilles/tmp/gilles-kde4"
> declare -x KDEVARTMP="/var/tmp/gilles-kde4"
38a45
> declare -x LD_LIBRARY_PATH="/opt/kde4/lib:"
50c57
< declare -x PATH="/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt4/bin:/home/gilles/bin:/usr/lib/qt4/bin"
---
> declare -x PATH="/usr/lib/qt4/bin:/opt/kde4/bin:/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt4/bin:/home/gilles/bin:/usr/lib/qt4/bin"
57c64
< declare -x QTDIR="/usr/lib/qt3"
---
> declare -x QTDIR="/usr/lib/qt4"
59a67
> declare -x QT_PLUGIN_PATH="/opt/kde4/lib/kde4/plugins"

Something similar must be done to run properly a KDE3 application
under Gnome for ex.

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