* imagemagick support on W32 @ 2010-10-01 1:44 Christoph 2010-10-01 1:52 ` Juanma Barranquero 0 siblings, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 1:44 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 1:44 imagemagick support on W32 Christoph @ 2010-10-01 1:52 ` Juanma Barranquero 2010-10-01 2:27 ` Christoph 0 siblings, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 1:52 UTC (permalink / raw) To: Christoph; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 1:52 ` Juanma Barranquero @ 2010-10-01 2:27 ` Christoph 2010-10-01 2:32 ` Christoph 0 siblings, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 2:27 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel [-- 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== ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 2:27 ` Christoph @ 2010-10-01 2:32 ` Christoph 2010-10-01 2:58 ` Christoph 0 siblings, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 2:32 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 2:32 ` Christoph @ 2010-10-01 2:58 ` Christoph 2010-10-01 3:16 ` Juanma Barranquero 0 siblings, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 2:58 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 2:58 ` Christoph @ 2010-10-01 3:16 ` Juanma Barranquero 2010-10-01 4:16 ` Christoph 0 siblings, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 3:16 UTC (permalink / raw) To: Christoph; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 3:16 ` Juanma Barranquero @ 2010-10-01 4:16 ` Christoph 2010-10-01 7:30 ` Eli Zaretskii 2010-10-01 10:37 ` Juanma Barranquero 0 siblings, 2 replies; 20+ messages in thread From: Christoph @ 2010-10-01 4:16 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 4:16 ` Christoph @ 2010-10-01 7:30 ` Eli Zaretskii 2010-10-01 10:37 ` Juanma Barranquero 1 sibling, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2010-10-01 7:30 UTC (permalink / raw) To: Christoph; +Cc: lekktu, emacs-devel > 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 4:16 ` Christoph 2010-10-01 7:30 ` Eli Zaretskii @ 2010-10-01 10:37 ` Juanma Barranquero 2010-10-01 11:36 ` joakim 2010-10-01 12:04 ` Christoph 1 sibling, 2 replies; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 10:37 UTC (permalink / raw) To: Christoph; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 10:37 ` Juanma Barranquero @ 2010-10-01 11:36 ` joakim 2010-10-01 12:12 ` Christoph 2010-10-01 19:51 ` Juanma Barranquero 2010-10-01 12:04 ` Christoph 1 sibling, 2 replies; 20+ messages in thread From: joakim @ 2010-10-01 11:36 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 11:36 ` joakim @ 2010-10-01 12:12 ` Christoph 2010-10-01 12:38 ` joakim 2010-10-01 19:51 ` Juanma Barranquero 1 sibling, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 12:12 UTC (permalink / raw) To: joakim; +Cc: Juanma Barranquero, emacs-devel 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)? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 12:12 ` Christoph @ 2010-10-01 12:38 ` joakim 2010-10-01 19:57 ` Juanma Barranquero 2010-10-02 3:31 ` Jason Rumney 0 siblings, 2 replies; 20+ messages in thread From: joakim @ 2010-10-01 12:38 UTC (permalink / raw) To: Christoph; +Cc: Juanma Barranquero, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 12:38 ` joakim @ 2010-10-01 19:57 ` Juanma Barranquero 2010-10-01 20:41 ` joakim 2010-10-02 3:31 ` Jason Rumney 1 sibling, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 19:57 UTC (permalink / raw) To: joakim; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 19:57 ` Juanma Barranquero @ 2010-10-01 20:41 ` joakim 0 siblings, 0 replies; 20+ messages in thread From: joakim @ 2010-10-01 20:41 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 12:38 ` joakim 2010-10-01 19:57 ` Juanma Barranquero @ 2010-10-02 3:31 ` Jason Rumney 1 sibling, 0 replies; 20+ messages in thread From: Jason Rumney @ 2010-10-02 3:31 UTC (permalink / raw) To: joakim; +Cc: Christoph, Juanma Barranquero, emacs-devel 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). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 11:36 ` joakim 2010-10-01 12:12 ` Christoph @ 2010-10-01 19:51 ` Juanma Barranquero 2010-10-01 20:44 ` joakim 1 sibling, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 19:51 UTC (permalink / raw) To: joakim; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 19:51 ` Juanma Barranquero @ 2010-10-01 20:44 ` joakim 2010-10-01 20:53 ` Juanma Barranquero 0 siblings, 1 reply; 20+ messages in thread From: joakim @ 2010-10-01 20:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 20:44 ` joakim @ 2010-10-01 20:53 ` Juanma Barranquero 0 siblings, 0 replies; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 20:53 UTC (permalink / raw) To: joakim; +Cc: Christoph, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 10:37 ` Juanma Barranquero 2010-10-01 11:36 ` joakim @ 2010-10-01 12:04 ` Christoph 2010-10-01 19:55 ` Juanma Barranquero 1 sibling, 1 reply; 20+ messages in thread From: Christoph @ 2010-10-01 12:04 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: imagemagick support on W32 2010-10-01 12:04 ` Christoph @ 2010-10-01 19:55 ` Juanma Barranquero 0 siblings, 0 replies; 20+ messages in thread From: Juanma Barranquero @ 2010-10-01 19:55 UTC (permalink / raw) To: Christoph; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-10-02 3:31 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-01 1:44 imagemagick support on W32 Christoph 2010-10-01 1:52 ` Juanma Barranquero 2010-10-01 2:27 ` Christoph 2010-10-01 2:32 ` Christoph 2010-10-01 2:58 ` Christoph 2010-10-01 3:16 ` Juanma Barranquero 2010-10-01 4:16 ` Christoph 2010-10-01 7:30 ` Eli Zaretskii 2010-10-01 10:37 ` Juanma Barranquero 2010-10-01 11:36 ` joakim 2010-10-01 12:12 ` Christoph 2010-10-01 12:38 ` joakim 2010-10-01 19:57 ` Juanma Barranquero 2010-10-01 20:41 ` joakim 2010-10-02 3:31 ` Jason Rumney 2010-10-01 19:51 ` Juanma Barranquero 2010-10-01 20:44 ` joakim 2010-10-01 20:53 ` Juanma Barranquero 2010-10-01 12:04 ` Christoph 2010-10-01 19:55 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).