[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: imagemagick support on W32
Re: imagemagick support on W32
Fri, 01 Oct 2010 13:36:32 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Juanma Barranquero <address@hidden> writes:
> On Fri, Oct 1, 2010 at 06:16, Christoph <address@hidden> 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.
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
Re: imagemagick support on W32, Christoph, 2010/10/01