[Digikam-users] potential incompatibility between exiv2-svn and exiv2-0.12
Gilles Caulier
caulier.gilles at gmail.com
Thu Mar 15 09:14:37 GMT 2007
libkexiv2 and digikam core fixed on svn.
Because we have a broken binary compatibility with shared lib, please update
and test by this way :
- cleanup all : Exiv2, libkexiv2, kipi-plugins, digiKam (make distclean).
- checkout source code everywhere.
- re-compile and install (using autotools included).
If you not do it, digiKam will crash... I'm sure, i have tested here...
Gilles
2007/3/15, Gilles Caulier <caulier.gilles at gmail.com>:
>
>
>
> 2007/3/14, Pedro Venda <pjvenda at pjvenda.org>:
> >
> > Hi everyone,
> >
> > I am facing another compilation error, for which I do not have enough
> > C++
> > experience to handle. I am compiling digikam along with trunk/exiv2
> > and trunk/extragear/libs, I have updated the svn copy of digikam several
> >
> > times and even rm -rf and rechecked the whole trees again to rule out
> > any
> > mess I might have made.
> >
> > The following error happens when compiling several objects from
> > digikam/libs/widgets/metadata/:
> >
> > if /bin/sh ../../../../libtool --silent --tag=CXX --mode=compile
> > g++ -DHAVE_CONFIG_H -I. -I. -I../../../..
> > -I../../../../digikam/libs/dmetadata -I../../../../digikam/libs/dimg
> > -I/usr/local/digikam-trunk/include -I../../../../digikam/digikam
> > -I/usr/kde/3.5/include -I/usr/qt/3/include -I.
> > -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi
> > -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
> > -Wpointer-arith -O2 -I/usr/local/digikam-trunk/include -Wformat-security
> > -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions
> > -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST
> > -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE
> > -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
> > -DQT_NO_TRANSLATION -fexceptions -MT
> > iptcwidget.lo -MD -MP -MF ".deps/iptcwidget.Tpo" -c -o iptcwidget.lo
> > iptcwidget.cpp; \
> > then mv -f ".deps/iptcwidget.Tpo" ".deps/iptcwidget.Plo"; else
> > rm -f ".deps/iptcwidget.Tpo"; exit 1; fi
> > iptcwidget.cpp: In member function 'virtual bool
> > Digikam::IptcWidget::decodeMetadata()':
> > iptcwidget.cpp:159: error: request for member 'c_str'
> > in '((Exiv2::Error*)e)->Exiv2::Error::what()', which is of non-class
> > type 'const char*'
> > iptcwidget.cpp: In member
> > function 'virtual QString Digikam::IptcWidget::getTagTitle(const
> > QString&)':
> > iptcwidget.cpp:188: error: request for member 'c_str'
> > in '((Exiv2::Error*)e)->Exiv2::Error::what()', which is of non-class
> > type 'const char*'
> > iptcwidget.cpp: In member
> > function 'virtual QString Digikam::IptcWidget::getTagDescription(const
> > QString&)':
> > iptcwidget.cpp:205: error: request for member 'c_str'
> > in '((Exiv2::Error*)e)->Exiv2::Error::what()', which is of non-class
> > type 'const char*'
> > make[5]: *** [iptcwidget.lo] Error 1
> >
> > I looked at the exiv2 error.hpp (exiv2-svn) header and I found that the
> > method
> > Exiv2::Error.what() already returns a (const char *) so c_str() is
> > (probably)
> > not adequate. The affected source files were: iptcwidget.cpp,
> > exifwidget.cpp,
> > gpswidget.cpp and makernotewidget.cpp.
> >
> > This what() method differs in the way it is being prototyped/implemented
> >
> > between exiv2-svn and exiv2-0.12 (error.hpp).
> > exiv2-svn is:
> > virtual const char* what() const throw() { return msg_.c_str();
> > }
> > exiv2-0.12 is:
> > virtual std::string what() const;
> >
> > The call to c_str() might work if called from a std::string object, but
> > not
> > from a const char * type variable (which is not even semantically
> > correct).
> > If I remove the call to c_str() on the affected objects, digikam
> > compiles
> > correctly but doesn't work. It starts and immediately after showing up
> > the
> > main screen, it segfaults with:
> >
> > terminate called after throwing an instance of 'std::bad_alloc'
> > what(): St9bad_alloc
>
>
> Normal. You haven't patched libkexiv2 library used by digiKam.
>
> Actually, digiKam depand of both. In the future, only the libkexiv2
> interface will be used.
>
> Gilles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20070315/c79d9ca1/attachment.html>
More information about the Digikam-users
mailing list