Re: building graphicsmagick 1.3.38 on Windows

Bob Friesenhahn <[email protected]> Sun, 17 Apr 2022 14:02:31 -0500 (CDT)
Newsgroups gmane.comp.video.graphicsmagick.core
Message-ID <[email protected]>
On Sun, 17 Apr 2022, LM wrote:

> First, the configure couldn't add libxml2 and freetype2
> It ignored the required packages/libraries from pkg-config.  So, configure
> couldn't compile sample programs with these libraries because required
> libraries were missing.  Had to add the libraries from iconv, bzip2, xz and
> mman to the LIBS variable to work-around it ignoring the pkg-config
> required libraries.  Then, I hit an issue when it tried to link using

I have deep distrust for pkg-config.  It's interfaces are not designed 
well (recent versions have improved).  The assumption is that it 
provides the information needed to use just one library, but this 
assumption fails when there are many libraries, with possibly 
conflicting requirements.  We end up with a summation of the 
libraries, which should still be ordered appropriately based on 
dependency order (libraries to the right satisfy the requirements of 
libraries to the left).

When using pkg-config there are not necessarily standard names for the 
packages and so the configure script needs to know what name has been 
used.

I do wonder what the problem is for libxml2 since in that case 
configure is using pkg-config?  For Freetype I see that output from a 
'freetype-config' (or 'freetype_config') script is used and it appears 
that this script is defunct.

Complete static linking is definitely a torture test.

> libxml2.  It couldn't find some of the functions in libxml2.  Ran across
> some information about the issue here:
> https://stackoverflow.com/questions/4984853/mingw-libxml2-issue
> Tried building with CPPFLAGS -DIN_LIBXML -DLIBXML_STATIC and that seemed to
> work-around that issue.

That is interesting.  Are you able to provide a list of the functions 
which were not found?  Perhaps they are not intended to be used by 
other software?

> Another problem, coders/msl.c, coders/svg.c, coders/url.c define _MSC_VER
> but they don't give the version they're defining it to.  There are multiple
> instances of code similar to #if (defined(_MSC_VER) && _MSC_VER >= 1500) in
> GraphicsMagick.  Luckily, it's not brought into those files after _MSC_VER

I was totally unaware of that!

> is defined or there would be errors that the left side of the _MSC_VER >=
> 1500 equation was undefined.  Unfortunately, some of the libraries I'm
> using have headers similar to this and they were being pulled into these
> files.  Was getting an error about _MSC_VER being undefined because the
> preprocessor is replacing _MSC_VER with nothing.  Changed the code in those
> 3 files to define _MSC_VER with a dummy version number to fix the problem.

I wonder why this has not been causing problems for me?  I used to 
compile with old MinGW32 regularly but most recently have found MSYS2 
to be very pleasing (although there have been some bumps in the road 
due to package publisher keys changing).

I have a recent MinGW32 on my system (providing GCC 9) but I forgot 
how to start it.

> Was able to get GraphicsMagick to build after adding those modifications to
> my build script.
>
> There's code at https://github.com/saitoha/ImageMagick-SIXEL to add sixel
> support to ImageMagick and it mentions that the code was integrated
> upstream with ImageMagick.  One reason I was trying to build the latest
> version of GraphicsMagick was to check if there was any sixel support.  I
> don't see it mentioned anywhere in the source.  I'm curious how difficult
> it would be to get the sixel code working with GraphicsMagick.  Of course,
> there are divergences between ImageMagick and GraphicsMagick, so it may not
> be as easy as I hope.  I was able to do something like that several years
> ago with another format.  However, seems even some of that code would no
> longer work since there have been changes to GraphicsMagick over time as
> well.  If anyone has any tips or ideas on adding other graphics formats
> like sixel to GraphicsMagick, would be interested to hear them.

While ImageMagick has made sweeping changes to function names, its 
fundamental properties remain similar to GraphicsMagick.  This means 
that it is not difficult to port code intended for ImageMagick to work 
with GraphicsMagick.

> One last subject I was curious about, I noticed SVG support in
> GraphicsMagick.  Didn't notice any SVG libraries mentioned, so I assume the
> support is all within the GraphicsMagick code.  Was wondering how the SVG
> support in GraphicsMagick compared to nanosvg and if it would be worth
> trying to integrate nanosvg or if the current SVG support is more than
> sufficient to do the same types of rendering.

My opinion regarding SVG in GraphicsMagick is that it works very well 
for some SVG and poorly for some other SVG.  If your usage is such 
that you can control the SVG formats to be rendered, then 
GraphicsMagick can work well.  If you need to handle some random SVG 
from the "Internet" then Chrome and Firefox will do best but this is 
not usually helpful for you.  The free SVG renderers such as Inkscape, 
rsvg, or cairosvg are typically biased (e.g. Inkscape prefers SVG that 
it writes) or have flaws.  If the SVG input is not trustworthy, then 
security becomes a major concern.

ImageMagick has similar issues with SVG.  It has a built in SVG 
renderer (the one that GraphicsMagick started with) but as normally 
delivered, it usually turns to some external renderer.  However, 
GraphicsMagick has more SVG development than ImageMagick does due to a 
substantial contribution from a knowledgeable volunteer.

GraphicsMagick has a few features still missing such as support for 
radial gradients, support for "large" gradients could be substantially 
improved, and there is no support for embedded font files, or 
downloading font files via a URL.

> I really like GraphicsMagick and prefer using it in place of ImageMagick,
> so thanks to everyone who supports and works on it to keep it going.

At the moment, that is primarily me. :-(

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt