Dear digikam users and bug/wish reporters,
now that digiKam 0.9.2-beta3 is released, this a good point where your help is needed: - could all of you please check their reported bugs and see if the problem still persists with the current implementation. For this just go to https://bugs.kde.org/query.cgi?GoAheadAndLogIn=1 and log in. At the bottom of that page you will find under "Preset Queries" the link "My Bugs". If the problem is solved, you directly close the bug (with a brief remark). If the problem persists, a short note and if possible updated information (back-traces etc.) would be very useful to fix the problem. - You could also review and update your votes for bugs/wishes so that after the release of 0.9.2 a priorization can be done by the digikam team, http://bugs.kde.org/votes.cgi?action=show_user Any help in adressing any of the other open bugs is of course very welcome as well! Currently the idea is that in about two weeks a bug-squashing week-end will be held to reduce the number of open issues, so any input before will be particularly helpful. Many thanks in advance, Arnd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Arnd Baecker wrote:
> Dear digikam users and bug/wish reporters, ... In the light of all this... I currently run Kubuntu and have DigiKam 0.9.1 from the distribution. I would very much like to run the newer SVN version, but that's when things get tricky; I have not been able to compile DigiKam from SVN for installation in ~/local/ while keeping the system-default DigiKam (and more importantly libkexiv and friends) in /usr. Compiling and installing the libraries works fine. The problem is; the DigiKam configure script relies on pkg-config to determine if the libkexiv2 version is sufficiently recent - in my setup, pkg-config looks at the wrong libkexiv2 and therefore falsely claims that my libkexiv2 is too old, and in turn configure won't generate Makefiles for DigiKam. I have compiled and installed libkexiv2 from SVN in ~/local/, but I also have a much older libkexiv2 in /usr/. It is simple to set the LD_LIBRARY_PATH etc. so that the right libkexiv2 *would* be used by the linker - however, pkg-config does not respect the library path when it tries to determine the version of the library - so while the right LD_LIBRARY_PATH is set for ld, pkg-config ignores that and reports the older /usr/ installed library version instead of the ~/local/ installed library that *would* have been used by ld. So, for me, ./configure in the DigiKam directory fails because pkg-config does not respect the LD_LIBRARY_PATH. Does anyone use the SVN versions of DigiKam and *not* install in /usr? I would really like to install DigiKam and libs in my home directory not in /usr - and I would like not to have to remove libkexiv2 and friends from /usr just to compile DigiKam for ~/local/. Is this possible? Or does everyone just overwrite libs under /usr ? -- Best regards, Jakob Oestergaard _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hi Jakob,
On Mon, 4 Jun 2007, Jakob Oestergaard wrote: > Arnd Baecker wrote: > > Dear digikam users and bug/wish reporters, > ... > > In the light of all this... > > I currently run Kubuntu and have DigiKam 0.9.1 from the distribution. I > would very much like to run the newer SVN version, but that's when > things get tricky; > > I have not been able to compile DigiKam from SVN for installation in > ~/local/ while keeping the system-default DigiKam (and more importantly > libkexiv and friends) in /usr. > > Compiling and installing the libraries works fine. The problem is; the > DigiKam configure script relies on pkg-config to determine if the > libkexiv2 version is sufficiently recent - in my setup, pkg-config looks > at the wrong libkexiv2 and therefore falsely claims that my libkexiv2 is > too old, and in turn configure won't generate Makefiles for DigiKam. I > have compiled and installed libkexiv2 from SVN in ~/local/, but I also > have a much older libkexiv2 in /usr/. > > It is simple to set the LD_LIBRARY_PATH etc. so that the right libkexiv2 > *would* be used by the linker - however, pkg-config does not respect the > library path when it tries to determine the version of the library - so > while the right LD_LIBRARY_PATH is set for ld, pkg-config ignores that > and reports the older /usr/ installed library version instead of the > ~/local/ installed library that *would* have been used by ld. > > So, for me, ./configure in the DigiKam directory fails because > pkg-config does not respect the LD_LIBRARY_PATH. > > Does anyone use the SVN versions of DigiKam and *not* install in /usr? I > would really like to install DigiKam and libs in my home directory not > in /usr - and I would like not to have to remove libkexiv2 and friends > from /usr just to compile DigiKam for ~/local/. > > Is this possible? Or does everyone just overwrite libs under /usr ? I always install to a separate place, following the instructions under "Install digiKam in your Home Directory" http://www.digikam.org/?q=download/svn And, yes there is a problem when an old exiv2 (etc.) lies around, see this message: http://mail.kde.org/pipermail/kde-imaging/2007-May/005106.html I have no idea if there are any plans to do anything on this. Also, this is a kde-imaging issue (not digikam ;-). Maybe you could file a bug report there? A temporary solution I use for myself is a small script which modifies the configure script for kde-imaging, see below (did not quite work last time, I had to change a few ones like this manually, but you will get the idea). HTH, Arnd ################ """ Hack to convince configure to find exiv2 stuff in a separate place, specified by PKG_CONFIG_PATH /tmp/NEWTRYSVNALL/libs mv configure configure_orig python ~/Digikam/Scripts/replace_makefile_mist.py > configure """ import os von='PKG_CONFIG_PATH="$prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_PATH"' nach='PKG_CONFIG_PATH=$PKG_CONFIG_PATH:"$prefix/lib${kdelibsuff}/pkgconfig"' von_='PKG_CONFIG_PATH="$kde_libs_prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_P ATH"' nach_='PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$kde_libs_prefix/lib${kdelibsuff}/pkgco nfig"' for line in open("configure_orig"): if "PKG_CONFIG_PATH" in line: line_ = line.replace(von, nach), print line_.replace(von_, nach_), else: print line, _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2007/6/4, Arnd Baecker <[hidden email]>: Hi Jakob, Or ping Angelo Nasalli about this problem on [hidden email] or [hidden email]. I think he is not on [hidden email]... Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Arnd Baecker
Arnd Baecker wrote:
> Hi Jakob, > Hi Arnd, ... > > I always install to a separate place, > following the instructions under > "Install digiKam in your Home Directory" > http://www.digikam.org/?q=download/svn That's exactly what I wanted to do (and *almost* did) :) > > And, yes there is a problem when an old exiv2 (etc.) lies around, > see this message: > http://mail.kde.org/pipermail/kde-imaging/2007-May/005106.html > I have no idea if there are any plans to do anything on this. > > Also, this is a kde-imaging issue (not digikam ;-). > Maybe you could file a bug report there? I would say that it is a pkg-config bug. The tool attempts to do something but doesn't do it well (why use a pkg config path and not the linker path when resolving library versions? that seems totally broken to me, unless I am missing something)) > A temporary solution I use for myself is a small script which > modifies the configure script for kde-imaging, see below > (did not quite work last time, I had to change a few > ones like this manually, but you will get the idea). I'll try that workaround tonight. Thanks! -- Best regards, Jakob Oestergaard _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Gilles and Jakob,
maybe I was wrong with my statement that this is not a digikam issue... Jakub, just to try to clarify the confusion which I may have created: - For the step svn co svn://anonsvn.kde.org/home/kde/branches/extragear/kde3/libs/ cd libs make -f Makefile.cvs ./configure --prefix=$DIGIKAMDEST --with-extra-includes=$DIGIKAMDEST/include --w ith-extra-libs=$DIGIKAMDEST/lib What is the output at the end of configure? - What is the output of the corresponding configure step for digikam? svn co -N svn://anonsvn.kde.org/home/kde/branches/extragear/kde3/graphics/ cd graphics svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin make -f Makefile.cvs ./configure -prefix=$DIGIKAMDEST --with-extra-includes=$DIGIKAMDEST/include --wi th-extra-libs=$DIGIKAMDEST/lib Independent of this, did you succeed last night? Best, Arnd On Mon, 4 Jun 2007, Jakob Oestergaard wrote: > Arnd Baecker wrote: > > Hi Jakob, > > > > Hi Arnd, > > ... > > > > I always install to a separate place, > > following the instructions under > > "Install digiKam in your Home Directory" > > http://www.digikam.org/?q=download/svn > > That's exactly what I wanted to do (and *almost* did) :) > > > > > And, yes there is a problem when an old exiv2 (etc.) lies around, > > see this message: > > http://mail.kde.org/pipermail/kde-imaging/2007-May/005106.html > > I have no idea if there are any plans to do anything on this. > > > > Also, this is a kde-imaging issue (not digikam ;-). > > Maybe you could file a bug report there? > > I would say that it is a pkg-config bug. The tool attempts to do > something but doesn't do it well (why use a pkg config path and not the > linker path when resolving library versions? that seems totally broken > to me, unless I am missing something)) > > > A temporary solution I use for myself is a small script which > > modifies the configure script for kde-imaging, see below > > (did not quite work last time, I had to change a few > > ones like this manually, but you will get the idea). > > I'll try that workaround tonight. Thanks! > > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Tuesday 05 June 2007 09:35:05 Arnd Baecker wrote:
> Gilles and Jakob, > > maybe I was wrong with my statement that > this is not a digikam issue... > > Jakub, just to try to clarify the confusion which I may have created: > - For the step > svn co svn://anonsvn.kde.org/home/kde/branches/extragear/kde3/libs/ > cd libs > make -f Makefile.cvs > ./configure --prefix=$DIGIKAMDEST > --with-extra-includes=$DIGIKAMDEST/include --w > ith-extra-libs=$DIGIKAMDEST/lib > > What is the output at the end of configure? > Everything is OK: ---------8<-----------8<------------------8<------------------8<------- -- Kipi-Plugins configure results ------------------- -- gphoto2 found.................. YES -- libkipi found.................. YES -- libkexiv2 library found........ YES -- libkdcraw library found........ YES -- libtiff found.................. YES -- libkcal found.................. YES -- imlib2 found................... YES -- OpenGL found................... YES -- libxslt found.................. YES -- libgpod found.................. YES -- libkdcraw configure results ------------------- -- lcms found..................... YES -- libkexiv2 configure results ------------------- -- Exiv2 library found............ YES Good - your configure finished. Start make now ---------8<-----------8<------------------8<------------------8<------- > - What is the output of the corresponding configure step for digikam? > svn co -N > svn://anonsvn.kde.org/home/kde/branches/extragear/kde3/graphics/ cd > graphics > svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin > > make -f Makefile.cvs > ./configure -prefix=$DIGIKAMDEST > --with-extra-includes=$DIGIKAMDEST/include --wi > th-extra-libs=$DIGIKAMDEST/lib > ---------8<-----------8<------------------8<------------------8<------- -- digiKam configure results ------------------- -- libsqlite3 library found....... YES -- libgphoto2 library found....... YES -- libkipi library found.......... YES -- libtiff library found..... .... YES -- libpng library found........... YES -- libjasper library found........ YES -- liblcms library found.......... YES -- libkexiv2 library found........ NO digiKam needs libkexiv2 library >= 0.1.4 You need to install libkexiv2 first libkexiv2 website is at http://www.kipi-plugins.org -- libkdcraw library found........ YES ------------------------------------------------ ---------8<-----------8<------------------8<------------------8<------- The problem with pkg-config being used to determine library versions while the tool does not respect the LD_LIBRARY_PATH can easily be seen: joe@lenin$ PKG_CONFIG_PATH=/home/joe/local/lib/pkgconfig/:/usr/lib/pkgconfig/ pkg-config --modversion libkexiv2 0.1.6 joe@lenin$ PKG_CONFIG_PATH=/usr/lib/pkgconfig/:/home/joe/local/lib/pkgconfig/ pkg-config --modversion libkexiv2 0.1.1 Since the makefiles (automake macro files) use a PKG_CONFIG_PATH where the system libraries come first, pkg-config will claim my libkexiv2 is too old, even if I set the linker path to prefer the new library to the old. In short; pkg-config is being used for something it cannot do. > > Independent of this, did you succeed last night? Well, no, I slept - sorry ;) Tonight, however, I managed to spend a little quality time with the laptop. I ran into a compilation problem though; looks like a missing commit (dmetadata.h, DMetaData::MetaDataMap missing). But the configure now works; thanks to your python magic (I changed it to perl because that was shorter and gave me a warm and fuzzy feeling inside, but it should be functionally equivalent to what you posted here): perl -pi -e 's/PKG_CONFIG_PATH="\$prefix\/lib\${kdelibsuff}\/pkgconfig: \$PKG_CONFIG_PATH"/PKG_CONFIG_PATH=\$PKG_CONFIG_PATH:"\$prefix\/lib\${kdelibsuff}\/pkgconfig"/' configure perl -pi -e 's/PKG_CONFIG_PATH="\$kde_libs_prefix\/lib\${kdelibsuff}\/pkgconfig: \$PKG_CONFIG_PATH"/PKG_CONFIG_PATH="\$PKG_CONFIG_PATH: \$kde_libs_prefix\/lib\${kdelibsuff}\/pkgconfig"/' configure -- Jakob Østergaard _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
So you only modified the configure in graphics
(but not the one in libs), right? So it seems that a solution would be to ensure that PKG_CONFIG_PATH always comes first in the configure? Gilles + other configure experts: is this something which can be fixed on the digikam side? (I don't really know anything about configure and all that ...) Best, Arnd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Tuesday 05 June 2007 22:20:08 Arnd Baecker wrote:
> So you only modified the configure in graphics > (but not the one in libs), right? > Right. > So it seems that a solution would be to ensure > that PKG_CONFIG_PATH always comes first in the configure? > No. That would reverse the fundamentally broken usage of pkg-configure in a manner so that it would work in my particular setup (and yours) but break in other setups (where path given to the linker will again differ from the PKG_CONFIG_PATH). It is the concept of having a PKG_CONFIG_PATH that is broken; the variable should not exist because it does not in any way relate to what paths the linker will search - what ever you set PKG_CONFIG_PATH to, it will either be "accidentally correct" or just plain wrong. Or, maybe I completely misunderstood the entire thing in which case I apologize and look forward to being enlightened :) > Gilles + other configure experts: > is this something which can be fixed on the digikam side? Personally, I think it would be very simple to version-check libraries that one controls (like libkdcraw) with a test program that uses the linker to link to the library and prints out a version string from the library. That would, by definition, always link to the library the linker chooses, and thus always print the correct answer. But again, I am in no way a configure expert and I could easily be missing a great deal of real-world configure details :) > > (I don't really know anything about configure and all that ...) > Thanks for your help and feedback, that was really useful! -- Jakob Østergaard _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Tue, 5 Jun 2007, Jakob [iso-8859-1] Østergaard wrote:
[...] > > Gilles + other configure experts: > > is this something which can be fixed on the digikam side? > > Personally, I think it would be very simple to version-check libraries that > one controls (like libkdcraw) with a test program that uses the linker to > link to the library and prints out a version string from the library. That > would, by definition, always link to the library the linker chooses, and thus > always print the correct answer. > > But again, I am in no way a configure expert and I could easily be missing a > great deal of real-world configure details :) While reviewing the crashes in the digikam B.K.O, I think the above issue is really important, e.g. I wanted to suggest for http://bugs.kde.org/show_bug.cgi?id=143200 to install the current beta3 but from the users system configuration I would suspect that he will end up with the same problem as discussed here ... Best, Arnd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2007/6/6, Arnd Baecker <[hidden email]>: On Tue, 5 Jun 2007, Jakob [iso-8859-1] Østergaard wrote: Marcel has normally fixed this one. Just try to reproduce it can be enough to check if all is ok... Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Wed, 6 Jun 2007, Gilles Caulier wrote:
> 2007/6/6, Arnd Baecker <[hidden email]>: [...] > > While reviewing the crashes in the digikam B.K.O, > > I think the above issue is really important, > > e.g. I wanted to suggest for > > http://bugs.kde.org/show_bug.cgi?id=143200 > > > Marcel has normally fixed this one. Just try to reproduce it can be enough > to check if all is ok... The problem is that I can't even perform the sequence (F2, CTRL+V, ENTER) in any meaning-ful way; maybe short-cuts have changed since then? So it would be good if the reporter would test it, because he knows what the sequence was supposed to do. However, with his system configuration he would not be able to install the current svn due to the wrong (==old) exiv2 (or libkexiv2) being found first... (i.e. http://mail.kde.org/pipermail/kde-imaging/2007-May/005106.html) Best, Arnd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2007/6/6, Arnd Baecker <[hidden email]>:
On Wed, 6 Jun 2007, Gilles Caulier wrote: So it would be good if the reporter would test it, because he knows what the sequence was supposed to do. sure... However, with his system configuration he would Yes, i seen it... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |