imagemagick support on W32

imagemagick support on W32

[Christoph]

I am trying to get imagemagick working on Windows. I added the support 
to the configure.bat file, downloaded the W32 package from the 
ImageMagick website and supplied the headers and libraries to 
configure.bat, like this:

configure.bat --no-cygwin --enable-checking --with-gcc --distfiles 
D:/devel/emacs/libXpm-3.5.8/src/libXpm.dll --cflags 
-IC:/Progra~2/GnuWin32/include --cflags 
-ID:/devel/emacs/libXpm-3.5.8/include --cflags 
-ID:/devel/emacs/libXpm-3.5.8/src --cflags 
-IC:/Progra~2/ImageMagick-6.6.4-Q16/include --ldflags 
-LC:/Progra~2/ImageMagick-6.6.4-Q16/lib --ldflags -lCORE_RL_wand_ 
--ldflags -lCORE_RL_magick_

I get the following output on `mingw32-make boostrap':

gcc -o oo-spd/i386/temacs.bin  -gdwarf-2 -g3  -mno-cygwin 
-LC:/Progra~2/ImageMagick-6.6.4-Q16/lib -lCORE_RL_wand_ 
-lCORE_RL_magick_ -Wl,-stack,0x00800000 -Wl,-heap,0x00100000 
-Wl,-image-base,0x01000000 -Wl,-subsystem,console -Wl,-entry,__start 
-Wl,-Map,oo-spd/i386/temacs.map oo-spd/i386/firstfile.o 
oo-spd/i386/emacs.res oo-spd/i386/temacs0.a oo-spd/i386/temacs1.a 
oo-spd/i386/temacw32.a oo-spd/i386
/lastfile.a -lwinmm -ladvapi32 -lgdi32 -lcomdlg32 -luser32 -lmpr 
-lshell32 -lwinspool -lole32 -lcomctl32 -lusp10
oo-spd/i386/temacs1.a(image.o): In function `Finit_image_library':
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:8630: undefined 
reference to `MagickWandGenesis'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:8631: undefined 
reference to `init_imagemagick_functions'
oo-spd/i386/temacs1.a(image.o): In function `Fimagemagick_types':
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7841: undefined 
reference to `GetMagickList'
oo-spd/i386/temacs1.a(image.o): In function `imagemagick_load_image':
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7483: undefined 
reference to `NewMagickWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7484: undefined 
reference to `MagickSetResolution'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7487: undefined 
reference to `MagickPingImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7494: undefined 
reference to `MagickGetNumberImages'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7502: undefined 
reference to `MagickGetNumberImages'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7505: undefined 
reference to `MagickGetNumberImages'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7508: undefined 
reference to `DestroyMagickWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7514: undefined 
reference to `CloneImageInfo'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7518: undefined 
reference to `AcquireExceptionInfo'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7520: undefined 
reference to `ReadImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7521: undefined 
reference to `CatchException'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7523: undefined 
reference to `NewMagickWandFromImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7543: undefined 
reference to `MagickGetImageHeight'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7544: undefined 
reference to `MagickGetImageWidth'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7558: undefined 
reference to `MagickScaleImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7624: undefined 
reference to `MagickGetImageHeight'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7625: undefined 
reference to `MagickGetImageWidth'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7753: undefined 
reference to `DestroyMagickWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7498: undefined 
reference to `DestroyMagickWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7491: undefined 
reference to `MagickPingImageBlob'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7527: undefined 
reference to `NewMagickWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7528: undefined 
reference to `MagickReadImageBlob'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7608: undefined 
reference to `NewPixelWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7609: undefined 
reference to `PixelSetColor'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7613: undefined 
reference to `MagickRotateImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7614: undefined 
reference to `DestroyPixelWand'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7593: undefined 
reference to `MagickCropImage'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7659: undefined 
reference to `NewPixelIterator'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7667: undefined 
reference to `MagickGetImageHeight'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7669: undefined 
reference to `PixelGetNextIteratorRow'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7674: undefined 
reference to `PixelGetMagickColor'
D:\devel\emacs\emacs-bzr\imagemagick\src/image.c:7682: undefined 
reference to `DestroyPixelIterator'
collect2: ld returned 1 exit status
mingw32-make[2]: *** [oo-spd/i386/temacs.exe] Error 1
mingw32-make[2]: Leaving directory 
`D:/devel/emacs/emacs-bzr/imagemagick/src'
mingw32-make[1]: *** [bootstrap-temacs] Error 2
mingw32-make[1]: Leaving directory 
`D:/devel/emacs/emacs-bzr/imagemagick/src'
mingw32-make: *** [bootstrap-gmake] Error 2

It seems like the linker cannot find the libraries provided despite the 
options point to the right location.

Looking at the gcc call above, it looks like my modifications to 
configure.bat are correct and the options are parsed out correctly.

I tried compiling an example from the ImageMagick website (wand.c) with 
ming32-gcc and the libraries seem to work fine.

Has anybody else tried this and got it to work? I can provide a patch 
bundle with my changes if anybody wants to test.

Christoph

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 03:44, Christoph <cschol2112@googlemail.com> wrote:

> I can provide a patch bundle
> with my changes if anybody wants to test.

Yes, please.

    Juanma

Re: imagemagick support on W32

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On 9/30/2010 7:52 PM, Juanma Barranquero wrote:
> On Fri, Oct 1, 2010 at 03:44, Christoph<cschol2112@googlemail.com>  wrote:
>
>> I can provide a patch bundle
>> with my changes if anybody wants to test.
>
> Yes, please.
>
>      Juanma

Find the bundle attached.

Christoph

[-- Attachment #2: ImageMagickW32-v1.txt --]
[-- Type: text/plain, Size: 6070 bytes --]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: cschol2112@gmail.com-20101001021447-7im3exf3jxezlv3c
# target_branch: http://bzr.savannah.gnu.org/r/emacs/trunk/
# testament_sha1: e040846506896569ffaca49ec27f40c58ff3db36
# timestamp: 2010-09-30 20:15:38 -0600
# base_revision_id: larsi@gnus.org-20100927205335-oiuk2p3qjp93s9p2
# 
# Begin patch
=== modified file 'nt/configure.bat'
--- nt/configure.bat	2010-09-22 23:14:00 +0000
+++ nt/configure.bat	2010-10-01 02:14:47 +0000
@@ -113,6 +113,7 @@
 if "%1" == "--without-gif" goto withoutgif
 if "%1" == "--without-tiff" goto withouttiff
 if "%1" == "--without-xpm" goto withoutxpm
+if "%1" == "--without-imagemagick" goto withoutimagemagick
 if "%1" == "--with-svg" goto withsvg
 if "%1" == "--distfiles" goto distfiles
 if "%1" == "" goto checkutils
@@ -135,6 +136,7 @@
 echo.   --without-gif           do not use GIF library even if it is installed
 echo.   --without-tiff          do not use TIFF library even if it is installed
 echo.   --without-xpm           do not use XPM library even if it is installed
+echo.   --without-imagemagick   do not use ImageMagick library even if it is installed
 echo.   --with-svg              use the RSVG library (experimental)
 echo.   --distfiles             path to files for make dist, e.g. libXpm.dll
 goto end
@@ -254,6 +256,16 @@
 shift
 goto again
 
+rem ----------------------------------------------------------------------
+
+:withoutimagemagick
+set imagemagicksupport=N
+set HAVE_IMAGEMAGICK=
+shift
+goto again
+
+rem ----------------------------------------------------------------------
+
 :withsvg
 shift
 set svgsupport=Y
@@ -561,6 +573,32 @@
 :xpmDone
 rm -f junk.c junk.obj
 
+if (%imagemagicksupport%) == (N) goto imagemagickDone
+
+echo Checking for ImageMagick...
+rem The following #define is needed to compile without error
+echo #define _NO_OLDNAMES >>junk.c
+echo #include "wand/MagickWand.h" >>junk.c
+echo main (){} >>junk.c
+rem   -o option is ignored with cl, but allows result to be consistent.
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
+if exist junk.obj goto haveImagemagick
+
+echo ...wand/MagickWand.h not found, building without ImageMagick support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
+
+set HAVE_IMAGEMAGICK=
+goto :imagemagickDone
+
+:haveImagemagick
+echo ...ImageMagick headers available, building with ImageMagick support.
+set HAVE_IMAGEMAGICK=1
+
+:imagemagickDone
+rm -f junk.c junk.obj
+
 if not (%svgsupport%) == (Y) goto :svgDone
 echo Checking for librsvg...
 echo #include "librsvg/rsvg.h" >junk.c
@@ -656,6 +694,7 @@
 if not "(%HAVE_GIF%)" == "()" echo #define HAVE_GIF 1 >>config.tmp
 if not "(%HAVE_TIFF%)" == "()" echo #define HAVE_TIFF 1 >>config.tmp
 if not "(%HAVE_XPM%)" == "()" echo #define HAVE_XPM 1 >>config.tmp
+if not "(%HAVE_IMAGEMAGICK%)" == "()" echo #define HAVE_IMAGEMAGICK 1 >>config.tmp
 if "(%HAVE_RSVG%)" == "(1)" echo #define HAVE_RSVG 1 >>config.tmp
 
 echo /* End of settings from configure.bat.  */ >>config.tmp
@@ -739,12 +778,18 @@
  echo   Install libtiff development files or use --without-tiff
 
 :checkgif
-if not "(%HAVE_GIF%)" == "()" goto checkdistfiles
+if not "(%HAVE_GIF%)" == "()" goto checkimagemagick
 if (%gifsupport%) == (N) goto checkdistfiles
  set libsOK=0
  echo GIF support is missing.
  echo   Install giflib or libungif development files or use --without-gif
 
+:checkimagemagick
+if not "(%HAVE_IMAGEMAGICK%)" == "()" goto checkdistfiles
+ set libsOK=0
+ echo ImageMagick support is missing.
+ echo   Install ImageMagick development files or use --without-imagemagick
+
 :checkdistfiles
 if "(%HAVE_DISTFILES%)" == "()" goto donelibchecks
 if (%distFilesOk%) == (1) goto donelibchecks

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWe/c2q4AAohfgAASWnf/93/v
3YC////6UAYZrSe2Q53o8O9w0Y6ru4SSTIaU9Gmmg0JoPSBPKek2oaNogDRkNBKQQ2poNJohoGgA
AAAAAAGQmgITTQymI1PU2kyEAMEPUZMg0AZVBkAGg0aBoNAaMmIGgNNqAASKJoaCCmnqHiZTaMJN
PU0yBkMgBo0NvBiiAe/1Dbp1OCVQ7hPVnYEuAH8ZMNHjvsnCy1pRQi8KMKpJCbexx8GXt/Rvxugz
fDx53/Jqn5dUaQCt3/vKL554t5nTQod66E2QPKpIBGcVhqhPdPfEhTQOtHKajtiIgAr8QcIW9cGH
LyL2eRXWTeWnRRCEe1XQPMR1deIGqvj2TeEvpCEc1a5fGR7/GGdz9ErpcDtqYlbbLdHnwNR/ZdTQ
eqd04s4y0W6Pbi0vQ0GFrt4VVkITRZUSJ1wDbXsyjFqFhRort1wS+u/Epet6C7lblyy56ADzFkIV
EAqPeYCPOd2SbL2A4JEzJlf6tbKAXW5rpzcDFHkVLTWmF6uoUJydZrohxPWtbF0Tq9MetuZ10RxT
fdiCCVgHhLAiGlOFM5HF4MNm/Zx1goYYdERSTDWMUBDgr6HUH+B4DoBumC0yd8zM4/z9BjB8AdSG
51u7l7YAGphaDLdyKxK+ohDhmjHLgtilwGQcuwpJLVfFNuvTq2DW0aduCapahnK9XjeS0rDJmihY
VmVaU4n4pSegcQonVmvGRg6iBxWQ1a+twIoTmNBDau8vjRTOoxY0KMMdpYuPmD4Ax2A3nWZzshuh
kcojPeLGYOhq8wU4u/FQwuFWuorFusWOUZbj8z5i70WNdEDpqvhykI5bmbLHYUFeMb9cclxbYgLc
Vkbgj5MiQvvK/7nJNESm3CRcYi9qV0NtfhdKhbpSqugPe8wMS9GFTQuKsaRufgjVNWK2oz4bCGzY
slSRvXTW1vbJs8HpMrRWo5ORWFM3XNnObEXWZDg5WQpK0U6+uJe0dSNbUNEcnIUAHT1JTvinQAiC
CEFoJrobMlAMYTvJMqEA+7bWNVpdxQKJ0NFo/yjubsAxCtiUgZjV8e67mdpl4C5YFelkIpRwYOTV
ALuyJEgG7Yez009FREtntA6waSxsBibaY1IYHv6eyO64snjjD+HedeJF5QfRvBijGb7Mbb+YJJXl
h4BUbMRKsi7yhG0Q3WNIqew+Bv7/Dtw95HOcddZhmBXJfqAjGyE9mTEs1WECL+5G/2tIOHDP86Eo
otv00vT02fkgvnl06+DrzaZPNZTHR0nSex77+CKrXBiczYaOgkpkNINdy7NUhE+nXrnqzm+3bIgT
MBSRGFBtZZkEYxJw/abmZRe5QwQxmVWVwThMVMbNWKc+9RtwA2klc2zRihu0hwOcOGp0+PZYsmiu
cQfMJzWUVVYedp4jTIVm9bFkt0EeFVq0wZkG7TPG8K5zQVUI8zshrCgNh41CSIiQu8CDVxWiqRIK
S7hfoLjOE7/6OFC90oAipKN6DHEksXlHxoDAwNPUnVNXNaTlzooYZEG8hkZFnCIu1FjWmJWHg15A
bv0AqWaDrTFrkOzSsWugJw2whuosy03oKdSpz84bPut6mA9wuQQagT0poOIHxsy3Q2gUBhSwhKIU
ZwyqAY23JxZhNBmdjwbQtmRlC/eKS8jrpStE+0CCYxFCS2gX1KrZqkOgjxtznINI2UiTwxUBQIFD
BQQoA7nAN7kcjrljOvqQFUMyp08CdSFCbwvlVmU6AQ3aAJAuTJMARQjxPUwIkLUyagWAHK8wO8mB
gRsxJeOCVBaXLcvFXtDMoG6kc1SWhKWV9S1Jy0tnTBh5CQUAhzAiRWrKIGPTY8Dng6aSFTEFUVCo
biAvNKi+q61Gu9doSjOFlYWOOKx9ajWFUKTjamBAc5UAWw6IEbluOWMihpg8Ktg3Y83QSEyjBgi9
4hMqlkLBjooC00qVmZkmKWDGIqFYQYlMr8aW3yyyhMMbtAKCWYL1hNZSTYZmWi8XSmZSaYZNdtxO
AcKbNeT7FGsTCLQox9tWQlS8vT/i7kinChId+5tVwA==

Re: imagemagick support on W32

[Christoph]

I found the linker problem. This is the correct way to configure:

configure.bat --no-cygwin --enable-checking --with-gcc --distfiles 
D:/devel/emacs/libXpm-3.5.8/src/libXpm.dll --cflags 
-IC:/Progra~2/GnuWin32/include --cflags 
-ID:/devel/emacs/libXpm-3.5.8/include --cflags 
-ID:/devel/emacs/libXpm-3.5.8/src --cflags 
-IC:/Progra~2/ImageMagick-6.6.4-Q16/include --ldflags 
-LC:/Progra~2/ImageMagick-6.6.4-Q16 --ldflags -lCORE_RL_magick_ 
--ldflags -lCORE_RL_wand_

i.e.

-LC:/Progra~2/ImageMagick-6.6.4-Q16

not

-LC:/Progra~2/ImageMagick-6.6.4-Q16/lib

Now the only problem is this:

Line 8631 of image.c:

return CHECK_LIB_AVAILABLE (&imagemagick_type, 
init_imagemagick_functions, libraries);

Where is init_imagemagick_functions defined?

For example, init_png_functions is defined in image.c, but 
init_imagemagick_functions is not.

Therefore, the linker complains about a missing reference to 
init_imagemagick_functions when linking with ImageMagick support on Windows.

I added a stub for this function in my code and now it compiles and 
links fine, but it will most likely blow up at runtime.

Christoph

Re: imagemagick support on W32

[Christoph]

On 9/30/2010 8:32 PM, Christoph wrote:

> Where is init_imagemagick_functions defined?

And if it is missing...does something like this come close?

#ifdef HAVE_NTGUI

DEF_IMGLIB_FN (MagickWandGenesis);
DEF_IMGLIB_FN (GetMagickList);
DEF_IMGLIB_FN (NewMagickWand);
DEF_IMGLIB_FN (MagickSetResolution);
DEF_IMGLIB_FN (MagickPingImage);
DEF_IMGLIB_FN (MagickGetNumberImages);
DEF_IMGLIB_FN (DestroyMagicWand);
DEF_IMGLIB_FN (CloneImageInfo);
DEF_IMGLIB_FN (AcquireExceptionInfo);
DEF_IMGLIB_FN (ReadImage);
DEF_IMGLIB_FN (CatchException);
DEF_IMGLIB_FN (NewMagickWandFromImage);
DEF_IMGLIB_FN (MagickGetImageHeight);
DEF_IMGLIB_FN (MagickGetImageWidth);
DEF_IMGLIB_FN (MagickScaleImage);
DEF_IMGLIB_FN (MagickPingImageBlob);
DEF_IMGLIB_FN (MagickReadImageBlob);
DEF_IMGLIB_FN (NewPixelWand);
DEF_IMGLIB_FN (PixelSetColor);
DEF_IMGLIB_FN (MagickRotateImage);
DEF_IMGLIB_FN (MagickCropImage);
DEF_IMGLIB_FN (NewPixelIterator);
DEF_IMGLIB_FN (PixelGetMagickColor);
DEF_IMGLIB_FN (DestroyPixelIterator);

static int
init_imagemagick_functions (Lisp_Object libraries)
{
   HMODULE library;

   /* Try loading ImageMagick library under probable names.  */
   if (!(library = w32_delayed_load (libraries, Qimagemagick)))
     return 0;

   LOAD_IMGLIB_FN (library, MagickWandGenesis);
   LOAD_IMGLIB_FN (library, GetMagickList);
   LOAD_IMGLIB_FN (library, NewMagickWand);
   LOAD_IMGLIB_FN (library, MagickSetResolution);
   LOAD_IMGLIB_FN (library, MagickPingImage);
   LOAD_IMGLIB_FN (library, MagickGetNumberImages);
   LOAD_IMGLIB_FN (library, DestroyMagicWand);
   LOAD_IMGLIB_FN (library, CloneImageInfo);
   LOAD_IMGLIB_FN (library, AcquireExceptionInfo);
   LOAD_IMGLIB_FN (library, ReadImage);
   LOAD_IMGLIB_FN (library, CatchException);
   LOAD_IMGLIB_FN (library, NewMagickWandFromImage);
   LOAD_IMGLIB_FN (library, MagickGetImageHeight);
   LOAD_IMGLIB_FN (library, MagickGetImageWidth);
   LOAD_IMGLIB_FN (library, MagickScaleImage);
   LOAD_IMGLIB_FN (library, MagickPingImageBlob);
   LOAD_IMGLIB_FN (library, MagickReadImageBlob);
   LOAD_IMGLIB_FN (library, NewPixelWand);
   LOAD_IMGLIB_FN (library, PixelSetColor);
   LOAD_IMGLIB_FN (library, MagickRotateImage);
   LOAD_IMGLIB_FN (library, MagickCropImage);
   LOAD_IMGLIB_FN (library, NewPixelIterator);
   LOAD_IMGLIB_FN (library, PixelGetMagickColor);
   LOAD_IMGLIB_FN (library, DestroyPixelIterator);

   return 1;
}

#endif /* HAVE_NTGUI */


Note: I wasn't sure about the #else clause for HAVE_NTGUI. Looks like 
for other image libraries the function names are aliased with 
fn_FUNCTIONNAME?

Christoph

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 04:58, Christoph <cschol2112@googlemail.com> wrote:

> And if it is missing...does something like this come close?

Yes, something like that, assuming you're trying to use ImageMagick
DLLs and not linking statically.

> Note: I wasn't sure about the #else clause for HAVE_NTGUI. Looks like for
> other image libraries the function names are aliased with fn_FUNCTIONNAME?

The code in image.c calls the image functions through the fn_ function
"pointers".

On HAVE_NTGUI, macros DEF_IMGLIB_FN and LOAD_IMGLIB_FN create and set
such pointers. On ! HAVE_NTGUI, such pointers are simply redefined to
refer to the original, statically linked functions.

So, the code that currently calls ImageMagick functions directly, like
NewMagickWand, MagickPingImage, etc, should be changed to call
fn_NewMagickWand, fn_MagickPingImage, etc.

One issue:

  /* Try loading ImageMagick library under probable names.  */
  if (!(library = w32_delayed_load (libraries, Qimagemagick)))
    return 0;

You'll have to add the imagemagick libraries to image-library-alist,
of course. But, what is the intention of ImageMagick here? To
substitute libpng, jpeglib, etc? If so, something will have to be done
with respect to image-type-available-p (or, more specifically,
init-image-library) so Emacs "knows" that png, jpeg, tiff, etc are
really available.

But perhaps I'm misinterpreting the intention of ImageMagick?

Hope this helps,

    Juanma

Re: imagemagick support on W32

[Christoph]

On 9/30/2010 9:16 PM, Juanma Barranquero wrote:

> Yes, something like that, assuming you're trying to use ImageMagick
> DLLs and not linking statically.

For now, I will go on with the dlls. On a side note: would Emacs require 
to use the .dlls or could the library also be statically linked in?

> On HAVE_NTGUI, macros DEF_IMGLIB_FN and LOAD_IMGLIB_FN create and set
> such pointers. On ! HAVE_NTGUI, such pointers are simply redefined to
> refer to the original, statically linked functions.
>
> So, the code that currently calls ImageMagick functions directly, like
> NewMagickWand, MagickPingImage, etc, should be changed to call
> fn_NewMagickWand, fn_MagickPingImage, etc.

That's what I figured. Thanks.

> One issue:
>
>    /* Try loading ImageMagick library under probable names.  */
>    if (!(library = w32_delayed_load (libraries, Qimagemagick)))
>      return 0;
>
> You'll have to add the imagemagick libraries to image-library-alist,
> of course. But, what is the intention of ImageMagick here? To
> substitute libpng, jpeglib, etc? If so, something will have to be done
> with respect to image-type-available-p (or, more specifically,
> init-image-library) so Emacs "knows" that png, jpeg, tiff, etc are
> really available.
>
> But perhaps I'm misinterpreting the intention of ImageMagick?

I assumed that that was the intention of the inclusion of the 
ImageMagick branch in the first place. Maybe there are other use cases 
though that I am not aware of.

Thanks for the image-library-alist hint.

Right now, everything compiles fine (with the addition of my own 
init_imagemagick_functions function, but when I run 
(imagemagick-register-types) Emacs crashes.

Run under gdb from the src/ directory the output is:

Program received signal SIGSEGV, Segmentation fault.
0x6d043295 in GetLastValueInLinkedList ()
    from 
D:\devel\emacs\emacs-bzr\imagemagick\src\oo-spd\i386\CORE_RL_magick_.dll

I try to dig around some more.

Christoph

Re: imagemagick support on W32

[Eli Zaretskii]

> Date: Thu, 30 Sep 2010 22:16:32 -0600
> From: Christoph <cschol2112@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> Right now, everything compiles fine (with the addition of my own 
> init_imagemagick_functions function, but when I run 
> (imagemagick-register-types) Emacs crashes.
> 
> Run under gdb from the src/ directory the output is:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6d043295 in GetLastValueInLinkedList ()
>     from 
> D:\devel\emacs\emacs-bzr\imagemagick\src\oo-spd\i386\CORE_RL_magick_.dll

What compiler was used to build the ImageMagick libraries?

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 06:16, Christoph <cschol2112@googlemail.com> wrote:

> For now, I will go on with the dlls. On a side note: would Emacs require to
> use the .dlls or could the library also be statically linked in?

In theory, you could statically link any library to Emacs, but IMO in
this case is much better to stick to using the DLLs. The library is
big, unneeded when you start with -nw or in -batch mode, and it's
easier to update as DLLs than recompiling/relinking Emacs (which the
common, non-developer user cannot do).

> I assumed that that was the intention of the inclusion of the ImageMagick
> branch in the first place.

OK.

> Thanks for the image-library-alist hint.

It shouldn't be difficult, but there are a few tricky details, I
think. If ImageMagick is loaded,
image-library-alist/init-image-library will have to act as if every
image type supported by ImageMagick is loaded (or there is a way to
ask ImageMagick for a list of the formats it support?) But even if
Emacs is compiled with ImageMagick support, a given instance could be
unable to load the libraries (not found in the path, or whatever), and
in this case, the other libraries could be loaded. Assuming, of
course, that compiling with ImageMagick support does not deactivate
(at compile time) the other image libraries' stuff. Does it?

> Right now, everything compiles fine (with the addition of my own
> init_imagemagick_functions function, but when I run
> (imagemagick-register-types) Emacs crashes.

Eli's question is very relevant. I had trouble in the past mixing
MSVC-compiled Emacs and MinGW-compiled image libraries; perhaps you're
seeing just the opposite. Both runtimes are not compatible; in fact,
if the library uses stdio facilities to access files you'll get all
kind of havoc. It'd be easier if you can compile ImageMagick with
MinGW.

    Juanma

Re: imagemagick support on W32

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 1, 2010 at 06:16, Christoph <cschol2112@googlemail.com> wrote:
>
>> For now, I will go on with the dlls. On a side note: would Emacs require to
>> use the .dlls or could the library also be statically linked in?
>
> In theory, you could statically link any library to Emacs, but IMO in
> this case is much better to stick to using the DLLs. The library is
> big, unneeded when you start with -nw or in -batch mode, and it's
> easier to update as DLLs than recompiling/relinking Emacs (which the
> common, non-developer user cannot do).
>
>> I assumed that that was the intention of the inclusion of the ImageMagick
>> branch in the first place.
>
> OK.

I'm not sure what the original question was, but I intended for
ImageMagick support to live alongside the other image loaders.

>> Thanks for the image-library-alist hint.
>
> It shouldn't be difficult, but there are a few tricky details, I
> think. If ImageMagick is loaded,
> image-library-alist/init-image-library will have to act as if every
> image type supported by ImageMagick is loaded (or there is a way to
> ask ImageMagick for a list of the formats it support?) But even if

There is, (imagemagick-types). You dont know for certain at compile time
which formats are available, because imagemagick supports a plugin
mechanism for new formats.

> Emacs is compiled with ImageMagick support, a given instance could be
> unable to load the libraries (not found in the path, or whatever), and
> in this case, the other libraries could be loaded. Assuming, of
> course, that compiling with ImageMagick support does not deactivate
> (at compile time) the other image libraries' stuff. Does it?


ImageMagick support does not deactivate the other loaders. They all live
together. Of course there will then be situations when its not clear
which loader should be used, because there are several candidates
available. The ImageMagick loader can be configured so it does not try
to load particular image formats, with imagemagick-types-inhibit. Which
particular loader gets used in a particular case is not completely
obvious however. I've made no attempt to change loader priorities, and
Imagemagick usualy gets last shot at loading a format, so when jpeg
support is compiled in, and imagemagick support is compiled in, the jpeg
loader wins by default.

>> Right now, everything compiles fine (with the addition of my own
>> init_imagemagick_functions function, but when I run
>> (imagemagick-register-types) Emacs crashes.
>
> Eli's question is very relevant. I had trouble in the past mixing
> MSVC-compiled Emacs and MinGW-compiled image libraries; perhaps you're
> seeing just the opposite. Both runtimes are not compatible; in fact,
> if the library uses stdio facilities to access files you'll get all
> kind of havoc. It'd be easier if you can compile ImageMagick with
> MinGW.
>
>     Juanma
>

-- 
Joakim Verona

Re: imagemagick support on W32

[Christoph]

On 10/1/2010 4:37 AM, Juanma Barranquero wrote:

> In theory, you could statically link any library to Emacs, but IMO in
> this case is much better to stick to using the DLLs. The library is
> big, unneeded when you start with -nw or in -batch mode, and it's
> easier to update as DLLs than recompiling/relinking Emacs (which the
> common, non-developer user cannot do).

That makes much sense.

> It shouldn't be difficult, but there are a few tricky details, I
> think. If ImageMagick is loaded,
> image-library-alist/init-image-library will have to act as if every
> image type supported by ImageMagick is loaded (or there is a way to
> ask ImageMagick for a list of the formats it support?) But even if
> Emacs is compiled with ImageMagick support, a given instance could be
> unable to load the libraries (not found in the path, or whatever), and
> in this case, the other libraries could be loaded. Assuming, of
> course, that compiling with ImageMagick support does not deactivate
> (at compile time) the other image libraries' stuff. Does it?

I guess Joakim answered this in his email. I will have a look at at 
that. Thanks.

> Eli's question is very relevant. I had trouble in the past mixing
> MSVC-compiled Emacs and MinGW-compiled image libraries; perhaps you're
> seeing just the opposite. Both runtimes are not compatible; in fact,
> if the library uses stdio facilities to access files you'll get all
> kind of havoc. It'd be easier if you can compile ImageMagick with
> MinGW.

I will answer Eli's question here. AFAIK, the libraries from 
ImageMagick's website are compiled with MSVC. I had read somewhere that 
MSVC/mingw libraries are mostly incompatible but figured I'd give it 
shot anyway, since my original problem was Emacs not finding the 
libraries during linking.

Now, I have tried compiling ImageMagick with mingw but that turned out 
to be a huge pita. I installed all necessary GnuWin32 libs, and even 
MSYS, and ./configure would fail with lots of problems still. It says it 
can't find some components of the different packages (jpeg, png etc.) 
and basically disabled the support for those. I do have all the GnuWin32 
dev packages installed and it finds most of the headers.

Sounds like I will have to sort that out after all and get some mingw 
dll's compiled first before going on.

Thanks,
Christoph

Re: imagemagick support on W32

[Christoph]

On 10/1/2010 5:36 AM, joakim@verona.se wrote:

> I'm not sure what the original question was, but I intended for
> ImageMagick support to live alongside the other image loaders.

OK.

> ImageMagick support does not deactivate the other loaders. They all live
> together. Of course there will then be situations when its not clear
> which loader should be used, because there are several candidates
> available. The ImageMagick loader can be configured so it does not try
> to load particular image formats, with imagemagick-types-inhibit. Which
> particular loader gets used in a particular case is not completely
> obvious however. I've made no attempt to change loader priorities, and
> Imagemagick usualy gets last shot at loading a format, so when jpeg
> support is compiled in, and imagemagick support is compiled in, the jpeg
> loader wins by default.

What if jpeg support is compiled in, but the library is unavailable (dll 
missing). Does it also go on to ImageMagick (if their dll is availble 
instead)?

Re: imagemagick support on W32

[joakim]

Christoph <cschol2112@googlemail.com> writes:

> On 10/1/2010 5:36 AM, joakim@verona.se wrote:
>
>> I'm not sure what the original question was, but I intended for
>> ImageMagick support to live alongside the other image loaders.
>
> OK.
>
>> ImageMagick support does not deactivate the other loaders. They all live
>> together. Of course there will then be situations when its not clear
>> which loader should be used, because there are several candidates
>> available. The ImageMagick loader can be configured so it does not try
>> to load particular image formats, with imagemagick-types-inhibit. Which
>> particular loader gets used in a particular case is not completely
>> obvious however. I've made no attempt to change loader priorities, and
>> Imagemagick usualy gets last shot at loading a format, so when jpeg
>> support is compiled in, and imagemagick support is compiled in, the jpeg
>> loader wins by default.
>
> What if jpeg support is compiled in, but the library is unavailable
> (dll missing). Does it also go on to ImageMagick (if their dll is
> availble instead)?

Im not really sure, but from reading image.c it seems that on non w32
plattforms the library stubs are just compiled in and called directly,
which means not having the library there would be runtime linkage error.

On w32 something different seems to happen, but no real effort seems to
be done to avoid errors if the desired library isnt there. I might be
wrong.

-- 
Joakim Verona

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 13:36,  <joakim@verona.se> wrote:

> I'm not sure what the original question was, but I intended for
> ImageMagick support to live alongside the other image loaders.

OK.

> There is, (imagemagick-types). You dont know for certain at compile time
> which formats are available, because imagemagick supports a plugin
> mechanism for new formats.

How does that integrate with image-types and image-type-available-p?

> so when jpeg
> support is compiled in, and imagemagick support is compiled in, the jpeg
> loader wins by default.

Seems sensible.

Thanks for explaining this,

    Juanma

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 14:04, Christoph <cschol2112@googlemail.com> wrote:

> I will answer Eli's question here. AFAIK, the libraries from ImageMagick's
> website are compiled with MSVC. I had read somewhere that MSVC/mingw
> libraries are mostly incompatible but figured I'd give it shot anyway, since
> my original problem was Emacs not finding the libraries during linking.

As said, they can sometimes be made to work together, but as soon as
they exchange filehandles, etc. you're out of luck.

> Now, I have tried compiling ImageMagick with mingw but that turned out to be
> a huge pita. I installed all necessary GnuWin32 libs, and even MSYS, and
> ./configure would fail with lots of problems still.

Don't use MSYS. That's short of a stripped down Cygwin, intended to
help compiling the MinGW tools.

> Sounds like I will have to sort that out after all and get some mingw dll's
> compiled first before going on.

Yes, likely. Good luck, and thanks for the effort.

    Juanma

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 14:38,  <joakim@verona.se> wrote:

> On w32 something different seems to happen, but no real effort seems to
> be done to avoid errors if the desired library isnt there. I might be
> wrong.

Run-time or compile-time? If the library support is compiled in,
failing to load the desired library at run time is not an error; the
image type will just be unavailable.

    Juanma

Re: imagemagick support on W32

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 1, 2010 at 14:38,  <joakim@verona.se> wrote:
>
>> On w32 something different seems to happen, but no real effort seems to
>> be done to avoid errors if the desired library isnt there. I might be
>> wrong.
>
> Run-time or compile-time?

Run-time

> If the library support is compiled in,
> failing to load the desired library at run time is not an error; the
> image type will just be unavailable.

Ok.

>     Juanma

-- 
Joakim Verona

Re: imagemagick support on W32

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 1, 2010 at 13:36,  <joakim@verona.se> wrote:
>
>> I'm not sure what the original question was, but I intended for
>> ImageMagick support to live alongside the other image loaders.
>
> OK.
>
>> There is, (imagemagick-types). You dont know for certain at compile time
>> which formats are available, because imagemagick supports a plugin
>> mechanism for new formats.
>
> How does that integrate with image-types and image-type-available-p?

Uhm, aparently not at all? Something must have gotten lost somewhere...

>> so when jpeg
>> support is compiled in, and imagemagick support is compiled in, the jpeg
>> loader wins by default.
>
> Seems sensible.
>
> Thanks for explaining this,
>
>     Juanma

-- 
Joakim Verona

Re: imagemagick support on W32

[Juanma Barranquero]

On Fri, Oct 1, 2010 at 22:44,  <joakim@verona.se> wrote:

> Uhm, aparently not at all? Something must have gotten lost somewhere...

The current interface, pre-ImageMagick patch, is that image-types says
which image types are supported (i.e., compiled in) by Emacs, and
image-type-available-p says which types are really available in the
running Emacs (of course for statically linked libraries these are
equivalent). The ImageMagick code should IMHO plug into the same
interface.

    Juanma

Re: imagemagick support on W32

[Jason Rumney]

joakim@verona.se writes:

> Im not really sure, but from reading image.c it seems that on non w32
> plattforms the library stubs are just compiled in and called directly,
> which means not having the library there would be runtime linkage error.
>
> On w32 something different seems to happen, but no real effort seems to
> be done to avoid errors if the desired library isnt there. I might be
> wrong.

If the desired library is not there, then image-type-available-p will
return nil for that image type (as if the library support were not
compiled in). That should be sufficient to avoid errors.

On other platforms, a missing library will result in Emacs failing to
start, but since modern GNU/Linux systems have good packaging tools that
resolve dependencies well, this shouldn't be a problem (and it shouldn't
be a problem for users who compile Emacs themselves unless they later
remove a library that was there before).