Version: (using KDE 3.5.8) Installed from: FreeBSD Ports Compiler: gcc (GCC) 4.2.1 20070719 [FreeBSD] OS: FreeBSD When trying to start digikam via shell, it creates the following error message: >digikam terminate called after throwing an instance of 'Exiv2::Error' what(): MakerTagInfo registry full Abort (core dumped)
What is the version of your libexiv2 are you using?
I'm using libexif-0.6.15
Not libexif ! libexiv2... Gilles Caulier
Oops, sorry :-( exiv2-0.16,1
What version of exiv2 was digikam compiled with? (I'm sure how to best check that, I think there is something like an "About" Window somewhere with version info, maybe that shows it.) Andreas
s/sure/not sure/
Well, it's not possible to use *any* window, since digikam won't start at all - it just aborts when trying to start it. As stated above: exiv2-0.16,1
yeah yeah of course, my bad. Can you find it out from the BSD package info?
This problem has come up before and so far was always a symptom for an invalid combination of versions. (Which shouldn't happen in the first place, there is something else wrong somewhere.) freshports.org lists the following releases for the relevant packages. If you install the libkexiv2 and exiv2 packages which were current at the release date of your version of digikam, does that fix the problem? digikam: 23-Dec-2007 0.9.3 18-Sep-2007 0.9.2_1 23-Jul-2007 0.9.2 libkexiv2: 07-Mar-2008 0.1.6_1 18-Sep-2007 0.1.6 02-Jul-2007 0.1.5 exiv2: 07-Mar-2008 0.16,1 23-Jul-2007 0.14,1
I'd be glad to test it - but I can't find the old version (0.14,1) of exiv2 anywhere :-(
Mark, At least, i recommend to only install one version of shared library to prevent confusion. I have already seen many report about incompatibility between shared library, especailly with Exiv2... Andreas, i suspect than older Exiv2 versions which don't use a standard ABI number can fragilize recent releases as well when both version are installed at the same time... In all cases, removing older Exiv2 releases fix the problem... Gilles Caulier
Mark, any update on this bug? Many thanks in advance, Arnd
Mark, any update on this bug? Otherwise it will be closed ... Many thanks in advance, Arnd
Hello, since digikam 0.9.4-beta5 I have exactly the problem described here. I run a openSuSE 10.3 system. I have libexiv2-2-0.16-17 and its devel package installed and compiled digikam with this config. This works fine. However when I start digikam it then tells me it cannot find libexiv2.so.0 . When I install additionally libexiv2-0.15-8.2 then digikam will start however then I get the "MakerTagInfo registry full" error. When I completely remove the rpms libexiv2-2-0.16-17 as well as libexiv2-devel-2-0.16-17 and only install libexiv2-0.15-8.2 as well as libexiv2-devel-0.15-8.2 and then recompile digikam everything works fine and no "MakerTagInfo registry full" error is shown. With digikam 0.9.4-beta4 I did not have this problem and beta4 still runs fine no matter if libexiv2-2-016-17 is installed or not.
Andreas, Your viewpoint about comment #14 ? Gilles Caulier
> When I install additionally libexiv2-0.15-8.2 then digikam will start > however then I get the "MakerTagInfo registry full" error. So does it load 0.15? Since digikam (and I assume libkexiv2) was compiled with exiv2 0.16, that would be the case I mentioned in comment #9. Digikam shouldn't even start in this case! (see below) > When I [...] only install libexiv2-0.15-8.2 as well as > libexiv2-devel-0.15-8.2 and then recompile digikam everything works fine > and no "MakerTagInfo registry full" error is shown. Compile and run the same versions of everything: works fine. That's fine. The questions are 1) When you installed libexiv2-2-0.16-17, you say "when I start digikam it then tells me it cannot find libexiv2.so.0". Why not? And why is it not looking for libexiv2.so.2 (see below)?? 2) When digikam was compiled with v0.16 and run with 0.15, why does it load the library in the first place? Here is a small illustration done using the tarballs from the exiv2 distribution: When I install exiv2 0.16 in /usr/local/lib, it installs libexiv2.so.2.1.0 libexiv2.so.2 -> libexiv2.so.2.1.0 libexiv2.so -> libexiv2.so.2.1.0 When I compile a small application (exifprint from the samples directory), I get $ ldd exifprint libexiv2.so.2 => /usr/local/lib/libexiv2.so.2 (0xb7de6000) (and several others) Now, I uninstall exiv2 0.16 and install 0.15 instead. In /usr/local/lib, it installs libexiv2.so.0.1.0 libexiv2.so.0 -> libexiv2.so.0.1.0 libexiv2.so -> libexiv2.so.0.1.0 When I now try to run the application compiled with 0.16, I get $ exiv2-0.16/samples/exifprint exiv2-0.16/samples/exifprint: error while loading shared libraries: libexiv2.so.2: cannot open shared object file: No such file or directory It doesn't even start! So I don't understand how it is possible to run digikam with exiv2 0.15 when it was compiled with exiv2 0.16 Do you have any other versions of exiv2 installed on your system? Or is it a problem with the exiv2 package of your distribution? Try the same thing that you did with the exiv2 distribution from www.exiv2.org to find out. I would expect similar results as those described above. -ahu.
Am Dienstag, 27. Mai 2008 18:01:25 schrieb Andreas Huggel: [bugs.kde.org quoted mail] I uninstalled the 0.16 rpm versions of exiv2 and then compiled the 0.16 version from source and installed it. After I recompiled digikam 0.9.4-beta5 it now works for me. It seems the exiv2-0.16 rpm I had caused the problem. digkam uses now /usr/lib/libexiv2.so.0 from libexiv2-0.15-8.2 but anyway it works. The 0.15 is still required for kde which links to this version. The 0.16 version was required for kde4. Rainer
So, this file can be closed now ? Gilles Caulier
Am Mittwoch, 28. Mai 2008 08:50:44 schrieb krienke@uni-koblenz.de: [bugs.kde.org quoted mail] I just found another explanaition for the "MakerTagInfo registry full". I just tried to start digikam from the souce directory. The installed version runs fine. If I however try to start $ ./digikam-0.9.4-beta5/digikam/digikam/digikam terminate called after throwing an instance of 'Exiv2::Error' what(): MakerTagInfo registry full Aborted So here I still get the this error allthogh the very same version of digikam is already installed and runs. Strange. Have anice day Rainer
Just curious, can you do $ ldd digikam from eg, your home directory and $ ldd ./digikam-0.9.4-beta5/digikam/digikam/digikam to see if they load the same exiv2 library? -ahu.
Am Mittwoch, 28. Mai 2008 13:02:54 schrieb Andreas Huggel: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > $ ldd /opt/kde3/bin/digikam | grep exiv2 libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73bd000) libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb72c4000) The digikam file in digikam-0.9.4-beta5/digikam/digikam is a bourne shell script. It says its a wrapper: # digikam - temporary wrapper script for .libs/digikam # .... It finally calls digikam-0.9.4-beta5/digikam/digikam/.libs/lt-digikam $ ldd digikam-0.9.4-beta5/digikam/digikam/.libs/lt-digikam | grep exiv2 libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73dd000) libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7260000) libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb595a000) Rainer
Andreas, This is the problem : libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7260000) libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb595a000) How it's possible ? Gilles
Yup. I suspect libkexiv2 loads one version and digikam is directly linked to another version. -ahu.
Andreas, But digiKam is not linked with Exiv2 directly (there is nothing in this way from the Makefile.am). Only libkexiv2 must do. It's a packaging problem ? Gilles
I think we can find out what is linked to libexiv2 by running ldd on each of the libraries digikam is linked to. Those that don't show up anywhere are directly linked to digikam. A bit tedious since there are many but I don't have a better idea. Rainer, since you have the interesting case with different versions, could you please do that? Start with libkexiv2 and then go through all the other libraries that digikam is linked to to see if any of them is linked to libexiv2. If not it must be digikam itself. I don't think it's a packaging problem, Rainer compiled this version of digikam himself. -ahu.
Am Mittwoch, 28. Mai 2008 15:08:43 schrieb Andreas Huggel: > Rainer, since you have the interesting case with different versions, could > you please do that? Start with libkexiv2 and then go through all the other > libraries that digikam is linked to to see if any of them is linked to > libexiv2. If not it must be digikam itself. Ok, what I did was to run this quite simple loop in the beta5 source tree: for i in `ldd digikam/digikam/.libs/lt-digikam | awk '{print $3}'`; do ldd $i|grep exiv2 && echo $i; done it does a ldd on all shared libs lt-digikam depends on and then does a ldd on each of these libs and greps all occurences of exiv2 and then echos the lib they were found in if there were any. The result is: libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73d0000) libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7252000) libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb5974000) /home/krienke/tmp/digikam/digikam-0.9.4-beta5/digikam/digikam/.libs/libdigikam.so.0 libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb7ea6000) /opt/kde3/lib/libkexiv2.so.3 So both libdigikam.so.0 links to exiv2 as well as libkexiv2.so.3 Is this what you wanted to see? Rainer
Rainer, Yes, thanks, good job! Gilles, The public libkexiv2 API "leaks" Exiv2 objects in at least 2 places: static void printExiv2ExceptionError(const QString& msg, Exiv2::Error& e); static QString convertCommentValue(const Exiv2::Exifdatum &comment); (I didn't check if it also throws Exiv2::Error out of the library) If these methods are used in digikam, then digikam must link to Exiv2. And if it links a different version than libkexiv2 then I'm not sure what will happen. Is it possible that you use Exiv2 objects only in the implementation of libkexiv2 and not in its API? (I suggest nowhere in kexiv2.h at all, not even in the private sections of the classes there) This includes that libkexiv2 shouldn't throw Exiv2 objects for digikam to catch. Having said that, I still don't really understand this bug. The error that we get is not caused by any of these calls directly, it happens during the initialization of Exiv2, before any client call is made. I've opened a bug for Exiv2 to replace this initialization code with something more straightforward (http://dev.robotbattle.com/mantis/view.php?id=550), maybe that will help too. -ahu.
> static void printExiv2ExceptionError(const QString& msg, Exiv2::Error& e); ==> Not used in digiKam > static QString convertCommentValue(const Exiv2::Exifdatum &comment); ==> Not used in digiKam > I didn't check if it also throws Exiv2::Error out of the library No isn't it.... > Is it possible that you use Exiv2 objects only in the implementation of >libkexiv2 and not in its API? (I suggest nowhere in kexiv2.h at all, not even >in the private sections of the classes there) This includes that libkexiv2 >shouldn't throw Exiv2 objects for digikam to catch. Yes, i will do it. Gilles
SVN commit 814354 by cgilles: libkexiv2 from trunk : reduce memory fingerprint and API simplifications: remove unecessary private methods to access on internal STD C++ and Exiv2 C++ components CCBUGS: 158989 M +4 -5 CMakeLists.txt M +15 -15 kexiv2.cpp M +4 -35 kexiv2.h M +5 -5 kexiv2comments.cpp M +0 -45 kexiv2private.cpp M +4 -2 kexiv2private.h WebSVN link: http://websvn.kde.org/?view=rev&revision=814354
SVN commit 814357 by cgilles: libkexiv2 from trunk : No need to redeclare internal Exiv2 components here. CCBUGS: 158989 M +0 -3 kexiv2.h WebSVN link: http://websvn.kde.org/?view=rev&revision=814357
SVN commit 814363 by cgilles: libkexiv2 from trunk : improve binary compatibility again. do not make visible all private methods from kexiv2.h Now, all Exiv2 components are unknow from host application which use libkexiv2 CCBUGS: 158989 M +2 -8 kexiv2.cpp M +242 -152 kexiv2.h M +1 -92 kexiv2comments.cpp M +30 -30 kexiv2exif.cpp M +8 -8 kexiv2gps.cpp M +11 -11 kexiv2image.cpp M +19 -19 kexiv2iptc.cpp M +106 -0 kexiv2private.h M +19 -19 kexiv2xmp.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=814363
Andreas, I have reassigned this file to libkexiv2 component in bugzilla Gilles
SVN commit 814370 by cgilles: digiKam from trunk : compile following libkexiv2 api changes CCBUGS: 158989 M +16 -14 libs/dmetadata/dmetadata.cpp M +4 -2 libs/widgets/metadata/exifwidget.cpp M +4 -2 libs/widgets/metadata/iptcwidget.cpp M +4 -2 libs/widgets/metadata/makernotewidget.cpp M +4 -2 libs/widgets/metadata/xmpwidget.cpp M +2 -0 project/project.kdevelop WebSVN link: http://websvn.kde.org/?view=rev&revision=814370
Andreas, I can't do more... Only libkexiv2 from trunk (KDE4) is fixed. libkexiv2 from KDE3 branch still as well, to preserve binary compatibility (libkexiv2 have just been released and digiKam/kipi-plugins are in beta release) Please, check (only) kexiv2.h from trunk. All Exiv2 component are now invisible from library host program. I have also removed unecessary private methods. http://websvn.kde.org/trunk/extragear/libs/libkexiv2/libkexiv2/kexiv2.h?revision=814371&view=markup If it's fine for you, i will close this file here and mark this file as resolved into libkexiv2 for KDE4 NEWS file. Best Gilles Caulier
Looks good. I've also fixed Exiv2 bug #550, it will be in 0.17 - if nothing else, that removes at least the symptom :) Did you find out why libdigikam.so links with exiv2? -ahu.
> Did you find out why libdigikam.so links with exiv2? Not yet. Like libkexiv2 0.17 have been released, i currently fix libkexiv2 for KDE3 in the same way than KDE4 version. Gilles
SVN commit 816063 by cgilles: libkexiv2 from KDE3 branch : binary compatibility is broken here. API change to export all Exiv2 access classes to internal private container. This fix is similar than last changes from KDE4 implementation. BUGS: 158989 M +1 -1 Makefile.am M +55 -299 kexiv2.cpp M +4 -51 kexiv2.h AM kexiv2private.cpp [License: GPL (v2+)] AM kexiv2private.h [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=816063
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4