Bug 161770 - KOffice does not build with GraphicsMagick 1.2.X
Summary: KOffice does not build with GraphicsMagick 1.2.X
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Compiled Sources Other
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
Keywords: triaged
Depends on:
Reported: 2008-05-07 23:23 UTC by Bob Friesenhahn
Modified: 2009-02-10 16:01 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Bob Friesenhahn 2008-05-07 23:23:14 UTC
Version:            (using Devel)
Installed from:    Compiled sources
OS:                Other

GraphicsMagick 1.2.X is released and is not 100% API compatible with GraphicsMagick 1.1.X.  Some long deprecated macros and functions (deprecated before GraphicsMagick existed) were removed.  Most significantly the complex profiles data structure has been removed from Image and replaced with a general purpose accessor/iterator API.  Given the significant performance, quality, and security improvements in GraphicsMagick 1.2.X, I expect that KDE will want to support it as soon as is reasonably possible.

This chunk of compiler error output was provided by someone who attempted to build Krita using GraphicsMagick 1.2.1:

031 	if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../krita -I../../../krita/core -I../../../krita/sdk -I../../../krita/core/tiles -I../../../krita/kritacolor -I../../../krita/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/usr/include/GraphicsMagick -I/usr/lib/qt-3.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 -DNDEBUG -DNO_DEBUG -O2 -O3 -march=i686 -mtune=i686 -m32 -fomit-frame-pointer -maccumulate-outgoing-args -pipe -fPIC  -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 -DHAVE_KNEWSTUFF -fexceptions -MT kis_image_magick_converter.lo -MD -MP -MF ".deps/kis_image_magick_converter.Tpo" -c -o kis_image_magick_converter.lo kis_image_magick_converter.cc; \
032 	then mv -f ".deps/kis_image_magick_converter.Tpo" ".deps/kis_image_magick_converter.Plo"; else rm -f ".deps/kis_image_magick_converter.Tpo"; exit 1; fi
033 	kis_image_magick_converter.cc: In function 'void<unnamed>::setAnnotationsForImage(const Image*, KisImageSP)':
034 	kis_image_magick_converter.cc:185: error: 'const struct _Image' has no member named 'generic_profiles'
035 	kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile'
036 	kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile'
037 	kis_image_magick_converter.cc:191: error: 'const struct _Image' has no member named 'generic_profile'
038 	kis_image_magick_converter.cc: In member function 'KisImageBuilder_Result KisImageMagickConverter::decode(const KURL&, bool)':
039 	kis_image_magick_converter.cc:483: error: 'Downscale' was not declared in this scope
040 	kis_image_magick_converter.cc:537: error: 'Downscale' was not declared in this scope
041 	kis_image_magick_converter.cc:581: error: 'Downscale' was not declared in this scope
042 	kis_image_magick_converter.cc:611: error: 'Downscale' was not declared in this scope
043 	kis_image_magick_converter.cc: In member function 'KisImageBuilder_Result KisImageMagickConverter::buildFile(const KURL&, KisPaintLayerSP, KSharedPtr<KisAnnotation>*, KSharedPtr<KisAnnotation>*)':
044 	kis_image_magick_converter.cc:815: error: 'Upscale' was not declared in this scope
045 	kis_image_magick_converter.cc:851: error: 'Upscale' was not declared in this scope
046 	kis_image_magick_converter.cc:882: error: 'Upscale' was not declared in this scope
047 	kis_image_magick_converter.cc: In static member function 'static QString KisImageMagickConverter::readFilters()':
048 	kis_image_magick_converter.cc:993: warning: unused variable 'matches'
049 	kis_image_magick_converter.cc: In static member function 'static QString KisImageMagickConverter::writeFilters()':
050 	kis_image_magick_converter.cc:1067: warning: unused variable 'matches'
051 	make[4]: *** [kis_image_magick_converter.lo] Error 1
Comment 1 Cyrille Berger 2008-05-08 08:42:04 UTC
It won't be fixed in 1.6 (since there won't be a new release) but it will definitively have to be fixed for 2.0. As different ABI version of a library can be installed side by ide I don't expect a problem for distribution for the time being.
Comment 2 Thomas Zander 2008-10-26 18:50:29 UTC
not a koffice bug
Comment 3 Cyrille Berger 2008-10-26 21:16:09 UTC
Actually I disagree. The main problem is that we use private API of GM to access profile data. And now that have hidden this even more :( But my take on this is: will remain broken for the moment, and GM filters should be disable when GM 1.2.X is found.
Comment 4 Bob Friesenhahn 2008-10-26 21:59:32 UTC
It is quite trivial to work around the profile access issue while using GM 1.1 APIs to do so.  This can be  done based on the knowledge that there are only a few profile IDs which are normally supported: "8BIM", "ICM", "IPTC", "XMP". The simple solution is to use GetImageProfile() in turn to request access to each profile type. If NULL is returned, then the image does not contain that profile.

Of course if there will never be another KDE release then there is no standard way to distribute the fix.  This is quite unfortunate for GraphicsMagick users since the slow adoption of newer KDE also slows the adoption of GraphicsMagick 1.2 (and soon 1.3) by a year or more.  There is four years of development between the GM 1.1 and 1.2 releases.
Comment 5 Cyrille Berger 2008-10-27 09:10:03 UTC
In fact what we would need is NextImageProfile but it's not available in 1.1 :( /me is going to resort to using #if )
Comment 6 Bob Friesenhahn 2008-10-27 16:27:13 UTC
I apologize for the API oversight in 1.1.X.  At least we got part of it right.  The generic profile interface was a nightmare. The iterator interface introduced in 1.2 should stand the test of time.
Comment 7 Cyrille Berger 2008-10-27 20:13:38 UTC
I just commited a change that should fix the compilation issue with GM 1.2, can anyone with koffice/trunk and GM 1.2 confirm that now it compiles ? If it does, I will make a patch for 1.6.x and offer it to packagers (we don't have the manpower for a full 1.6 release, but still we don't want to prevent other project to progress ;) )
Comment 8 Cyrille Berger 2008-11-03 12:59:20 UTC
SVN commit 879490 by berger:

an other attempt to check for version number, sounds like GM 1.2 has a smaller version number than 1.1 (not sure if 1.3 will keep that trend too...)

 M  +2 -1      kis_image_magick_converter.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=879490
Comment 9 Cyrille Berger 2008-11-03 13:07:26 UTC
SVN commit 879499 by berger:

compilation fix

 M  +1 -1      kis_image_magick_converter.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=879499
Comment 10 Cyrille Berger 2008-11-03 13:10:42 UTC
SVN commit 879505 by berger:


 M  +1 -1      kis_image_magick_converter.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=879505
Comment 11 Bob Friesenhahn 2008-11-03 16:27:44 UTC
If you can explain what you mean by "smaller version number" then surely I can clear things up.  I don't see any smaller version numbers.  Here is the info from magick/version.h:

From 1.1:
#define MagickLibVersion  0x0100014
#define MagickLibVersionText  "1.1.14"
#define MagickLibVersionNumber 1,0,14
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "2008-06-05"

From 1.2:
#define MagickLibVersion  0x020005
#define MagickLibVersionText  "1.2.5"
#define MagickLibVersionNumber 2,0,5
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "2008-07-25"

From development 1.3:
#define MagickLibVersion  0x030000
#define MagickLibVersionText  "1.3"
#define MagickLibVersionNumber 3,0,0
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "unreleased"

From the above, I think it is clear that MagickLibVersion is best to use in the code when checking for baseline API features.  Due to continuing maintenance, it is possible for the date of a lesser release to be greater than a more modern one.

Comment 12 Cyrille Berger 2008-11-03 16:40:00 UTC
Hi Bob,

Well 0x0100014 > 0x020005, it's best seen that way:
The last translate to

I wouldn't have noticed either ;) Unless the test had failed.

Well I guess it's a typo :/ That's why I usually prefer to divide a library version number in 
And if someone trully need a single number, then construct the single number from the three other number.
Comment 13 Bob Friesenhahn 2008-11-03 18:44:46 UTC
Ugh.  Here is how the value is computed in the GM configure script:

# Definition used to define MagickLibVersion in version.h
# As soon as any of these values exceeds 9, a more sophisticated formatting
# scheme must be invented for this string.

Notice the comment about if a value exceeds 9 that a different formatting scheme must be invented.  Apparently I never expected a release to be maintained through so many minor iterations and I totally forgot about this issue. This means that correct version numering was maintained until release 1.1.9, after which it became bogus.

Since these values are computed dynamically in the configure script I can't use something convenient and unportable like shell sprintf.
Comment 14 Cyrille Berger 2009-02-10 16:01:18 UTC
As far as I know, it should be fixed.