This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some questions about ImageMagick and cygwin

On Sat, 6 Dec 2003, Charles Wilson wrote:

> It looks like we have a sucker^W volunteer to contribute (and maintain)
> an ImageMagick package for the cygwin platform.  However, a few
> packaging questions have arisen.  I raise a bunch of issues below, but I
> do have a solution -- and a question (or three).

Your long email with so many twisty turns makes my brain hurt. :-)

BTFW that I (and most other previous ImageMagick developers) have not
been on the ImageMagick project since the end of November, 2002 at the
time ImageMagick 5.5.2 was released.  We staff the GraphicsMagick
project instead (

Regardless, since ImageMagick principally obtains its configure/build
environment and install footprint from GraphicsMagick (so that it can
leverage our work), I am still in a position to answer your questions.

> Because IM provides two shared libraries that can be used from other
> third party applications, the DLLs need to 'live' in their own,
> versioned, package -- like we do for ncurses, for instance:

Correction: IM and GM provide three shared libraries now.  The new one
is for the "Wand" API (authored by John Cristy) which is intended to
provide a simplified C programming interface for *Magick.

> Now, let us assume that in the fullness of time, package "FOO" is
> released which uses libMagick.  So, it's linked against cygMagick-6.dll.
>   Then, there's a new release of ImageMagick, version 5.9.2 or whatever,
> which has an API breakage, leading to cygMagick-7.dll.  Fine and dandy.
> But IM shared libs "know" about their modules directories; they load
> their modules -- which can be "dropped in" at any time of course --
> specifically from the **compiled in** path: in this case,
> /usr/lib/ImageMagick-5.5.7/*.  (let's call this "MODULEDIR")  Now, if
> the files in MODULEDIR are part of the 'ImageMagick' package, then when
> I upgrade to the ImageMagick-5.9.2-1 package, it will replace
> (uninstall) my old IM-5.5.7 package.  So
>     /usr/lib/ImageMagick-5.5.7/* goes away, to be replaced by
>     /usr/lib/ImageMagick-5.9.2/*
> But now my poor cygMagick-6.dll (which is still needed by the FOO
> package, remember) can't find its modules (and it can't use the 5.9.2
> modules, of course).

This would be a good time to remind you that it is not necessary to
use the complicated "modules" build.  There is also a "moby" DLL build
which is what you get if you specify --enable-shared but not

The main reason to use modules are:

  1) Decouple Magick library from optional/rare add-on libraries.
  2) Make licensing for non-GNU/proprietary apps easier by allowing
     removal of modules, or avoiding dependence on an optional GPLed
  3) Allow components to be added later by 3rd parties to extend the

The "moby" DLL build is now enabled to load modules in recent IM/GM
versions so it is not necessary to deliver a package with modules in
order to satisfy the user extensibilty of item #3.

> So here's my solution which solves (almost) all of these problems (but
> has two minor drawbacks of its own).
> Version the main DLLs using -release ${MAJ}.${MIN}.${MICRO}
> I know it's not libtool-blessed to do that, but the coordination between
> the main dlls, the modules and third-party users of the IM software
> suite -- e.g. package "FOO" or, if you like, GraphicsMagick :-) --
> causes all kinds of management and upgrade issues as detailed above, at
> least on Cygwin/Windows.  I haven't thought thru the problem on "normal"
> unix so maybe it's not a big deal there; but my gut tells me that it IS
> an issue even on normal unix.
> So, you'd end up with
>    libMagick5.5.7 package  which contains
>        cygMagick-5-5-7.dll
>        cygMagick++-5-5-7-dll
>        (actually named "libMagick5.5.7-5.5.7-1.tar.bz2, so
>         PKG="libMagick5.5.7" VER="5.5.7" and REL="1")
>    ImageMagick5.5.7 which contains
>        /usr/lib/ImageMagick-5.5.7/*
>        (tarball named "ImageMagick5.5.7-5.5.7-1.tar.bz2")
>    libMagick-devel
>        contains implibs, statlibs, and headers for "the most recent"
>        cygwin release of ImageMagick.
>        (tarball named "libMagick-devel-5.5.7-1.tar.bz2")
>    ImageMagick
>        contains the application binaries and man pages for "the most
>        recent" cygwin release of ImageMagick.  Each new release would
>        require: the libMagick* package and the ImageMagick* package whose
>        name equals "my" version.  So the tarball named
>        "ImageMagick-5.5.7-1.tar.bz2" would require:
>           libMagick5.5.7 (-5.5.7-1.tar.bz2) and
>           ImageMagick5.5.7 (-5.5.7-1.tar.bz2)
> This does not solve the "MARKER TWO" problem above, but that merely
> means "cygwin cannot change the API in cygwin-specific ways, except when
> coupled with a new upstream release -- even if that upstream release
> does not itself change the API"
> The other minor drawback with my solution is that it would lead to users
> -- even users who do not install the FOO package -- having lots and lots
> of cygMagick-X-Y-Z.dll's and /usr/lib/ImageMagick-X.Y.Z/ directories,
> unless they manually, every once in a while, uninstall the old
> "libMagickX.Y.Z" and "ImageMagickX.Y.Z" packages.
> So here's my (first) question:
> Back in the 5.5.2 days (around early November of 2002) the CVS version
> of IM **did** in fact, use -release to version the main dlls.  That
> changed somewhere along the way to -versioninfo.  However, I can find no
> record of when, why, or who, as the simplesystems CVS is gone and the
> cvs only has records going back to late March of 2003.
> It appears that all cvs history prior to that is gone.

I added -release to ImageMagick 5.5.2 since it had become clear that
ImageMagick had no desire/intention to accomplish and maintain binary
ABI compatibility.  GraphicsMagick removed -release since supporting
binary ABI compatibility is one of our basic precepts.  ImageMagick
then removed it in order to be like GraphicsMagick.  There is no
indication that ImageMagick will start issuing ABI compatible formal
releases, although it does silently produce dash release packages
which may or may not be ABI compatible with the original base release.

The simplesystems CVS is not really gone.  It was a live ImageMagick
repository (actually the original one!) which was converted into a
GraphicsMagick repository.  All of the ImageMagick history from late
4.8.X releases up to 5.5.2 is contained in GraphicsMagick CVS.  We do
not believe in discarding history.  See for how to access it.

> So: why was this change made, and can it (should it) be reverted back to
> -release?  If not for every platform, what is the advisability of our
> cygwin maintainer making that change for his cygwin releases?  Is there
> a way to do "#if CYGWIN then libMagick_LDFLAGS = -release ..... else
> libMagick_LDFLAGS = -version-info ...." ?

If there is a driving need to do so, it is certainly possible to
support -release for Cygwin.  This is only advisible if the libraries
do not assure ABI compatibility, or Cygwin is broken.

> ------------------
> Two more questions:
> 2.
> ImageMagick-5.5.7/guide/ contains two files whose names differ only in
> case.  This is bad -- one or the other should be renamed:
>    montage.tex
>    Montage.tex
> (you can check for this -- even on windows/cygwin -- using:
>    tar tvzf ImageMagick-5.5.7.tar.gz | awk '{print $6}' | \
>      grep -v "$/" | sort -f | uniq -i -d
> )

This is an ImageMagick problem which has since been corrected for
GraphicsMagick.  In fact, the guide directory has been deprecated for
GraphicsMagick since it is not actually the source for the guide.
The actual source is a home-grown XML-style format which is processed
using sed scripts into a number of other formats (including Latex).

> 3.
> Harold's current packaging script, attempting to follow cygwin's
> convention for the location of text documentation, does this:
>    mv /usr/share/ImageMagick-5.5.7/* /usr/share/doc/ImageMagick-5.5.7/
> e.g. text documentation goes in a {$PKG}-${VER} directory under
> /usr/share/doc. (**A**)
> But the stuff in /usr/share/ImageMagick-5.5.7/ is not ALL text
> documentation, is it?  For instance, .../image/patterns/* are actually
> used your "patterns" module, right?  So moving those would break things?

No.  This not true.  The image/patterns directory only exists to
support the HTML documentation.  The patterns are actually embedded in
the logo module.

For the 1.1 release of GraphicsMagick, the share directory is all
documentation except for a 'config' subdirectory containing
configuration files.  These same configuration files will also be
found if placed in lib/GraphicsMagick-1.1/config, but they are under
share since they are installation & platform independent.

> OTOH, the stuff in ..../image/* (excluding patterns/) are used by the
> HTML docu in ..../www ? so THAT would be fair game for Harolds manual,
> cygwin-specific, relocating into /usr/share/doc/ImageMagick-5.5.7/image/
> and .../www/, correct?  Along with the (actual text documentation and
> index.html) stuff in /usr/share/ImageMagick-5.5.7/ itself? (**A**)

The files in image/* and www/* are only used to support the HTML

So, in summary, I suggest that you consider using the "moby" DLL build
instead of the module build since that avoids a lot of headaches.
Cygwin is already GPL and has a good automated packaging system so
dependencies should not be a big issue. User-provided modules will
still be loaded, but once they are installed, there is a similar
headache.  Don't worry about the patterns directory.

Oh, and if an application links against *Magick.a for the modules
build the dependent application will be loading the DLL modules,
assuming that Windows supports a static app loading DLL modules.

Bob Friesenhahn

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]