64-bit build on Windows

64-bit build on Windows

[Juanma Barranquero]

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

Hi.

I've been able to build 64-bit Emacs on Windows with MSYS2. Generally,
things went smoothly, except for a couple of small problems.


This fragment in nt/INSTALL.64:

  Note also that we need to disable Imagemagick because Emacs does not yet
  support it on Windows.

    PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
    ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick

is entirely correct, but confusing if you happen to read it too quickly or
carelessly (as I did). The note talks about Imagemagick, but the sample
command also includes the setting of PKG_CONFIG_PATH (the only time that
pkg-config is mentioned in the file). So my brain dismissed the
PKG_CONFIG_PATH line, and went straight for the "./configure [...]
--without-imagemagick" part. That didn't end too well.


I also used msys2_shell.cmd (though nt/INSTALL.W64 clearly says not to) and
got into trouble with the guessed build machine. To be fair, I was misled
because nt/INSTALL.64 talks about mingw64_shell.bat, and that file doesn't
exist anymore, at least on the default MSYS2 setup you get by following our
suggested step-by-step guide. There are new executables mingw32.exe and
mingw64.exe, and using the latter I finished the build without further
trouble. But surely nt/INSTALL.64 should be fixed to refer to the new
launchers, or perhaps include a pointer to
https://sourceforge.net/p/msys2/wiki/Launchers/.

    Juanma

[-- Attachment #2: Type: text/html, Size: 1638 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 20 Jan 2017 02:40:32 +0100
> 
> I've been able to build 64-bit Emacs on Windows with MSYS2. Generally, things went smoothly, except for a
> couple of small problems.

Feel free to suggest changes for INSTALL.W64.

Thanks.

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Fri, Jan 20, 2017 at 9:06 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Feel free to suggest changes for INSTALL.W64.

Yes, of course, once determined what we want to say.

[-- Attachment #2: Type: text/html, Size: 378 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 21 Jan 2017 19:29:51 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Feel free to suggest changes for INSTALL.W64.
> 
> Yes, of course, once determined what we want to say.

We definitely don't want to say anything that is inaccurate or
confusing.

Re: 64-bit build on Windows

[Phillip Lord]

Juanma Barranquero <lekktu@gmail.com> writes:
> I've been able to build 64-bit Emacs on Windows with MSYS2. Generally,
> things went smoothly, except for a couple of small problems.
>
>
> This fragment in nt/INSTALL.64:
>
>   Note also that we need to disable Imagemagick because Emacs does not yet
>   support it on Windows.
>
>     PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
>     ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick
>
> is entirely correct, but confusing if you happen to read it too quickly or
> carelessly (as I did). The note talks about Imagemagick, but the sample
> command also includes the setting of PKG_CONFIG_PATH (the only time that
> pkg-config is mentioned in the file). So my brain dismissed the
> PKG_CONFIG_PATH line, and went straight for the "./configure [...]
> --without-imagemagick" part. That didn't end too well.


Hmmm. Well, I am not using --without-imagemagick for my builds. And,
besides, if it is not supported should it not be the default?

Phil

Re: 64-bit build on Windows

[Óscar Fuentes]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Hmmm. Well, I am not using --without-imagemagick for my builds. And,
> besides, if it is not supported should it not be the default?

The problem consists on Emacs' build system not detecting the presence
of Imagemagick version 7.x, which is what MSYS2 distributes. Angelo
Graziosi submitted a patch on this mailing list 7 days ago but AFAIK it
was not incorporated into Emacs yet.

FWIW I build Emacs on MSYS2 and --without-imagemagick seems unnecessary.
The configure script just says that Imagemagick is absent.

I have no idea about PKG_CONFIG_PATH. The MSYS2 recipe does not mention
it and seems to work just fine.

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 20 Jan 2017 15:32:04 +0100
> 
> phillip.lord@russet.org.uk (Phillip Lord) writes:
> 
> > Hmmm. Well, I am not using --without-imagemagick for my builds. And,
> > besides, if it is not supported should it not be the default?
> 
> The problem consists on Emacs' build system not detecting the presence
> of Imagemagick version 7.x, which is what MSYS2 distributes. Angelo
> Graziosi submitted a patch on this mailing list 7 days ago but AFAIK it
> was not incorporated into Emacs yet.
> 
> FWIW I build Emacs on MSYS2 and --without-imagemagick seems unnecessary.
> The configure script just says that Imagemagick is absent.

There's no problem when Imagemagick is absent.  The --without-*
switches are only needed when the package is present, but you want to
override its automatic detection.

AFAIR, the problem with Imagemagick support on Windows is that it can
only be supported when linked in statically, so the produced binary
can only be safely used on the system where it was built.  And on top
of that, there's a problem with Imagemagick 7.x, which I think is not
specific to Windows.

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-20 16:54 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

>
> AFAIR, the problem with Imagemagick support on Windows is that it can
> only be supported when linked in statically,


I don't think so. The patch I posted recently shows that emacs can be
compiled
with ImageMagick exactly the same way it is compiled with other dlls.

Fabrice

[-- Attachment #2: Type: text/html, Size: 711 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 20 Jan 2017 20:51:47 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
>  AFAIR, the problem with Imagemagick support on Windows is that it can
>  only be supported when linked in statically, 
> 
> I don't think so. The patch I posted recently shows that emacs can be compiled
> with ImageMagick exactly the same way it is compiled with other dlls.

Can be built before the patch or after the patch?  And after it is
built, will it run on a system where ImageMagick is not installed at
all?

You see, w32-win.el doesn't have ImageMagick-related DLL names in its
value of dynamic-library-alist, and without that Emacs won't know
which libraries to look for when ImageMagick support is requested.

That alist is how officially supported optional libraries should be
introduced into the Windows build of Emacs -- we want a binary that
was built with these libraries to be able to run on systems without
the DLLs being available.  By contrast, just linking with the -lLIB
link-time switch produces a binary that will refuse to load if the DLL
is not found.

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-21 19:25 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Fri, 20 Jan 2017 20:51:47 +0100
> > Cc: Óscar Fuentes <ofv@wanadoo.es>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> >  AFAIR, the problem with Imagemagick support on Windows is that it can
> >  only be supported when linked in statically,
> >
> > I don't think so. The patch I posted recently shows that emacs can be
> compiled
> > with ImageMagick exactly the same way it is compiled with other dlls.
>
> Can be built before the patch or after the patch?


After the patch.


> And after it is
> built, will it run on a system where ImageMagick is not installed at
> all?
>

My point is : ImageMagick is made available by dynamically loading 2 dlls.
If they are not installed, then the feature is disabled (as far as I
remember).

What happens if the jpeg or xpm or png dlls are not found ?

>
> You see, w32-win.el doesn't have ImageMagick-related DLL names in its
> value of dynamic-library-alist, and without that Emacs won't know
> which libraries to look for when ImageMagick support is requested.
>
>
It is easy enough to add them and if the patch I posted didn't address this
issue,
this is my mistake. Because it is certainly needed.

Fabrice

[-- Attachment #2: Type: text/html, Size: 2245 bytes --]

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Sat, Jan 21, 2017 at 8:04 PM, Fabrice Popineau <
fabrice.popineau@gmail.com> wrote:

> My point is : ImageMagick is made available by dynamically loading 2 dlls.
> If they are not installed, then the feature is disabled (as far as I
remember).

If Emacs on Windows is built to use the DLLs, and they are not available
(let's say you downloaded a binary tarball built with Imagemagick support,
but you don't have the DLLs in your system), Windows won't allow emacs.exe
to run. That's a big problem.

> What happens if the jpeg or xpm or png dlls are not found ?

Nothing, because they are not statically linked. If Emacs was built with
jpeg support (or png, etc.), it will check at runtime (and on demand, the
first time a jpeg function is needed) that the jpeg DLL can be loaded. If
not, the function will fail and Emacs will take note that the DLL is
unavailable.

    Juanma
​

[-- Attachment #2: Type: text/html, Size: 1467 bytes --]

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-21 20:15 GMT+01:00 Juanma Barranquero <lekktu@gmail.com>:

> On Sat, Jan 21, 2017 at 8:04 PM, Fabrice Popineau <
> fabrice.popineau@gmail.com> wrote:
>
> > My point is : ImageMagick is made available by dynamically loading 2
> dlls.
> > If they are not installed, then the feature is disabled (as far as I
> remember).
>
> If Emacs on Windows is built to use the DLLs, and they are not available
> (let's say you downloaded a binary tarball built with Imagemagick support,
> but you don't have the DLLs in your system), Windows won't allow emacs.exe
> to run. That's a big problem.
>
>
???

Not when you use LoadLibrary and fortunately.


> > What happens if the jpeg or xpm or png dlls are not found ?
>
> Nothing, because they are not statically linked. If Emacs was built with
> jpeg support (or png, etc.), it will check at runtime (and on demand, the
> first time a jpeg function is needed) that the jpeg DLL can be loaded. If
> not, the function will fail and Emacs will take note that the DLL is
> unavailable.
>
>
And it is the same for ImageMagick.

Fabrice

[-- Attachment #2: Type: text/html, Size: 2221 bytes --]

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Sat, Jan 21, 2017 at 8:23 PM, Fabrice Popineau <
fabrice.popineau@gmail.com> wrote:

> ???
>
> Not when you use LoadLibrary and fortunately.

I thought we were talking about statically linking Imagemagick. Of course
if it is not statically linked and you use LoadLibrary the problem does not
exist.

> And it is the same for ImageMagick.

It is already using dynamic-library-alist?

[-- Attachment #2: Type: text/html, Size: 588 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 21 Jan 2017 20:23:29 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
>  If Emacs on Windows is built to use the DLLs, and they are not available (let's say you downloaded a
>  binary tarball built with Imagemagick support, but you don't have the DLLs in your system), Windows
>  won't allow emacs.exe to run. That's a big problem.
> 
> ???
> 
> Not when you use LoadLibrary and fortunately.

The coe that uses LoadLibrary is based on dynamic-library-alist, so as
long as Imagemagick DLLs are not in that alist, there's no LoadLibrary
to load them.

>  > What happens if the jpeg or xpm or png dlls are not found ? 
> 
>  Nothing, because they are not statically linked. If Emacs was built with jpeg support (or png, etc.), it will
>  check at runtime (and on demand, the first time a jpeg function is needed) that the jpeg DLL can be
>  loaded. If not, the function will fail and Emacs will take note that the DLL is unavailable.
> 
> And it is the same for ImageMagick. 

Please describe how this would work, without using
dynamic-library-alist.

Re: 64-bit build on Windows

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 1623 bytes --]

2017-01-21 20:55 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sat, 21 Jan 2017 20:23:29 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, Óscar Fuentes <ofv@wanadoo.es>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> >  If Emacs on Windows is built to use the DLLs, and they are not
> available (let's say you downloaded a
> >  binary tarball built with Imagemagick support, but you don't have the
> DLLs in your system), Windows
> >  won't allow emacs.exe to run. That's a big problem.
> >
> > ???
> >
> > Not when you use LoadLibrary and fortunately.
>
> The coe that uses LoadLibrary is based on dynamic-library-alist, so as
> long as Imagemagick DLLs are not in that alist, there's no LoadLibrary
> to load them.
>
> >  > What happens if the jpeg or xpm or png dlls are not found ?
> >
> >  Nothing, because they are not statically linked. If Emacs was built
> with jpeg support (or png, etc.), it will
> >  check at runtime (and on demand, the first time a jpeg function is
> needed) that the jpeg DLL can be
> >  loaded. If not, the function will fail and Emacs will take note that
> the DLL is unavailable.
> >
> > And it is the same for ImageMagick.
>
> Please describe how this would work, without using
> dynamic-library-alist.
>

But I never said that it would work without using dynamic-library-alist ?
I said that I may have missed that part of the patch when I have posted it.
I was objecting to the fact that IM has to be statically linked.

The attached patch should be a proof of concept.

Fabrice

[-- Attachment #1.2: Type: text/html, Size: 2447 bytes --]

[-- Attachment #2: master-imagemagick.diff --]
[-- Type: text/plain, Size: 13983 bytes --]

diff --git a/configure.ac b/configure.ac
index dcba7eb..53a2d27 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2462,7 +2461,7 @@ AC_DEFUN
   if test "${with_imagemagick}" != "no"; then
     ## 6.3.5 is the earliest version known to work; see Bug#17339.
     ## 6.8.2 makes Emacs crash; see Bug#13867.
-    IMAGEMAGICK_MODULE="Wand >= 6.3.5 Wand != 6.8.2"
+    IMAGEMAGICK_MODULE="MagickWand >= 6.3.5 MagickWand != 6.8.2"
     EMACS_CHECK_MODULES([IMAGEMAGICK], [$IMAGEMAGICK_MODULE])
     AC_SUBST(IMAGEMAGICK_CFLAGS)
     AC_SUBST(IMAGEMAGICK_LIBS)
diff --git a/lisp/loadup.el b/lisp/loadup.el
index ecb7284..6921ed8 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -280,6 +280,7 @@
       (load "term/w32-win")
       (load "disp-table")
       (when (eq system-type 'windows-nt)
+        (load "image")
         (load "w32-fns")
         (load "ls-lisp")
         (load "dos-w32"))))
diff --git a/lisp/term/w32-win.el b/lisp/term/w32-win.el
index fda9388..d168e11 100644
--- a/lisp/term/w32-win.el
+++ b/lisp/term/w32-win.el
@@ -271,6 +271,8 @@ libgnutls-version
        '(gdk-pixbuf "libgdk_pixbuf-2.0-0.dll")
        '(glib "libglib-2.0-0.dll")
        '(gobject "libgobject-2.0-0.dll")
+       '(magickwand "libMagickWand-7.Q16HDRI-0.dll" "libMagickWand-7.Q16-0.dll")
+       '(magickcore "libMagickCore-7.Q16HDRI-0.dll" "libMagickCore-7.Q16-0.dll")
        (if (>= libgnutls-version 30400)
            '(gnutls "libgnutls-30.dll")
          '(gnutls "libgnutls-28.dll" "libgnutls-26.dll"))
diff --git a/src/image.c b/src/image.c
index 39677d2..04480f3 100644
--- a/src/image.c
+++ b/src/image.c
@@ -2307,7 +2403,7 @@ x_find_image_fd (Lisp_Object file, int *pfd)
              happens, e.g., under Auto Image File Mode.)  'openp'
              didn't open the file, so we should, because the caller
              expects that.  */
-	  fd = emacs_open (SSDATA (file_found), O_RDONLY, 0);
+          fd = emacs_open (SSDATA (file_found), O_RDONLY | O_BINARY, 0);
 	}
     }
   else	/* fd < 0, but not -2 */
@@ -8244,16 +8382,227 @@ imagemagick_image_p (Lisp_Object object)
 /* The GIF library also defines DrawRectangle, but its never used in Emacs.
    Therefore rename the function so it doesn't collide with ImageMagick.  */
 #define DrawRectangle DrawRectangleGif
+#ifdef __MINGW64__
+#include <ImageMagick-7/MagickWand/MagickWand.h>
+#else
 #include <wand/MagickWand.h>
+#endif
 
 /* ImageMagick 6.5.3 through 6.6.5 hid PixelGetMagickColor for some reason.
    Emacs seems to work fine with the hidden version, so unhide it.  */
+#ifdef __MINGW64__
+#include <ImageMagick-7/MagickCore/version.h>
+#else
 #include <magick/version.h>
+#endif
 #if 0x653 <= MagickLibVersion && MagickLibVersion <= 0x665
 extern WandExport void PixelGetMagickColor (const PixelWand *,
                                             MagickPixelPacket *);
 #endif
 
+#ifdef WINDOWSNT
+DEF_DLL_FN (MagickWand *, CloneMagickWand, (const MagickWand *));
+DEF_DLL_FN (MagickWand *, DestroyMagickWand, (MagickWand *));
+DEF_DLL_FN (MagickWand *, DestroyPixelIterator, (PixelIterator *));
+DEF_DLL_FN (PixelWand *, DestroyPixelWand, (PixelWand *));
+DEF_DLL_FN (MagickBooleanType, MagickCropImage, (MagickWand *, const size_t, const size_t, const ssize_t, const ssize_t));
+#ifdef HAVE_MAGICKEXPORTIMAGEPIXELS
+DEF_DLL_FN (MagickBooleanType, MagickExportImagePixels, (MagickWand *, const ssize_t, const ssize_t, const size_t, const size_t, const char *, const StorageType, void *));
+#endif
+DEF_DLL_FN (char *, MagickGetException, (const MagickWand *, ExceptionType *));
+DEF_DLL_FN (MagickWand *, MagickGetImage, (MagickWand *));
+DEF_DLL_FN (DisposeType, MagickGetImageDelay, (MagickWand *));
+DEF_DLL_FN (DisposeType, MagickGetImageDispose, (MagickWand *));
+DEF_DLL_FN (size_t, MagickGetImageHeight, (MagickWand *));
+DEF_DLL_FN (MagickBooleanType, MagickGetImagePage, (MagickWand *, size_t *, size_t *, ssize_t *, ssize_t *));
+DEF_DLL_FN (char *, MagickGetImageSignature, (MagickWand *));
+DEF_DLL_FN (size_t, MagickGetImageWidth, (MagickWand *));
+DEF_DLL_FN (size_t, MagickGetNumberImages, (MagickWand *));
+#ifdef HAVE_MAGICKMERGEIMAGELAYERS
+DEF_DLL_FN (MagickWand *, MagickMergeImageLayers, (MagickWand *, const ImageLayerMethod));
+#else
+DEF_DLL_FN (MagickWand *, MagickFlattenImages, (MagickWand *));
+#endif
+DEF_DLL_FN (MagickBooleanType, MagickReadImage, (MagickWand *, const char *));
+DEF_DLL_FN (MagickBooleanType, MagickReadImageBlob, (MagickWand *, const void *, const size_t));
+DEF_DLL_FN (void *, MagickRelinquishMemory, (void *));
+DEF_DLL_FN (MagickBooleanType, MagickRotateImage, (MagickWand *, const PixelWand *, const double));
+DEF_DLL_FN (MagickBooleanType, MagickScaleImage, (MagickWand *, const size_t, const size_t));
+DEF_DLL_FN (MagickBooleanType, MagickSetFilename, (MagickWand *, const char *));
+DEF_DLL_FN (MagickBooleanType, MagickSetImageBackgroundColor, (MagickWand *, const PixelWand *));
+DEF_DLL_FN (MagickBooleanType, MagickSetIteratorIndex, (MagickWand *, const ssize_t));
+DEF_DLL_FN (void, MagickWandGenesis, (void));
+DEF_DLL_FN (void, MagickWandTerminus, (void));
+DEF_DLL_FN (MagickWand *, NewMagickWand, (void));
+DEF_DLL_FN (PixelIterator *, NewPixelIterator, (MagickWand *));
+DEF_DLL_FN (PixelWand *, NewPixelWand, (void));
+DEF_DLL_FN (double, PixelGetAlpha, (const PixelWand *));
+DEF_DLL_FN (void, PixelGetMagickColor, (const PixelWand *, PixelInfo *));
+DEF_DLL_FN (PixelWand **, PixelGetNextIteratorRow, (PixelIterator *, size_t *));
+DEF_DLL_FN (MagickBooleanType, PixelSetIteratorRow, (PixelIterator *, const ssize_t));
+DEF_DLL_FN (void, PixelSetPixelColor, (PixelWand *, const PixelInfo *));
+DEF_DLL_FN (void, PixelSetRed, (PixelWand *, const double));
+DEF_DLL_FN (void, PixelSetGreen, (PixelWand *, const double));
+DEF_DLL_FN (void, PixelSetBlue, (PixelWand *, const double));
+DEF_DLL_FN (MagickBooleanType, PixelSyncIterator, (PixelIterator *));
+
+DEF_DLL_FN (ExceptionInfo *, DestroyExceptionInfo, (ExceptionInfo *));
+DEF_DLL_FN (char *, DestroyString, (char *));
+DEF_DLL_FN (ExceptionInfo *, AcquireExceptionInfo, ());
+DEF_DLL_FN (char **, GetMagickList, (const char *, size_t *, ExceptionInfo *));
+
+static bool
+init_imagemagick_functions (void)
+{
+  HMODULE magickwand, magickcore;
+
+  if (!(magickcore = w32_delayed_load (Qmagickcore))
+      || !(magickwand = w32_delayed_load (Qmagickwand)))
+    return 0;
+
+  LOAD_DLL_FN (magickwand, CloneMagickWand);
+  LOAD_DLL_FN (magickwand, DestroyMagickWand);
+  LOAD_DLL_FN (magickwand, DestroyPixelIterator);
+  LOAD_DLL_FN (magickwand, DestroyPixelWand);
+  LOAD_DLL_FN (magickwand, MagickCropImage);
+#ifdef HAVE_MAGICKEXPORTIMAGEPIXELS
+  LOAD_DLL_FN (magickwand, MagickExportImagePixels);
+#endif
+  LOAD_DLL_FN (magickwand, MagickGetException);
+  LOAD_DLL_FN (magickwand, MagickGetImage);
+  LOAD_DLL_FN (magickwand, MagickGetImageDelay);
+  LOAD_DLL_FN (magickwand, MagickGetImageDispose);
+  LOAD_DLL_FN (magickwand, MagickGetImageHeight);
+  LOAD_DLL_FN (magickwand, MagickGetImagePage);
+  LOAD_DLL_FN (magickwand, MagickGetImageSignature);
+  LOAD_DLL_FN (magickwand, MagickGetImageWidth);
+  LOAD_DLL_FN (magickwand, MagickGetNumberImages);
+#ifdef HAVE_MAGICKMERGEIMAGELAYERS
+  LOAD_DLL_FN (magickwand, MagickMergeImageLayers);
+#else
+  LOAD_DLL_FN (magickwand, MagickFlattenImages);
+#endif
+  LOAD_DLL_FN (magickwand, MagickReadImage);
+  LOAD_DLL_FN (magickwand, MagickReadImageBlob);
+  LOAD_DLL_FN (magickwand, MagickRelinquishMemory);
+  LOAD_DLL_FN (magickwand, MagickRotateImage);
+  LOAD_DLL_FN (magickwand, MagickScaleImage);
+  LOAD_DLL_FN (magickwand, MagickSetFilename);
+  LOAD_DLL_FN (magickwand, MagickSetImageBackgroundColor);
+  LOAD_DLL_FN (magickwand, MagickSetIteratorIndex);
+  LOAD_DLL_FN (magickwand, MagickWandGenesis);
+  LOAD_DLL_FN (magickwand, MagickWandTerminus);
+  LOAD_DLL_FN (magickwand, NewMagickWand);
+  LOAD_DLL_FN (magickwand, NewPixelIterator);
+  LOAD_DLL_FN (magickwand, NewPixelWand);
+  LOAD_DLL_FN (magickwand, PixelGetAlpha);
+  LOAD_DLL_FN (magickwand, PixelGetMagickColor);
+  LOAD_DLL_FN (magickwand, PixelGetNextIteratorRow);
+  LOAD_DLL_FN (magickwand, PixelSetIteratorRow);
+  LOAD_DLL_FN (magickwand, PixelSetPixelColor);
+  LOAD_DLL_FN (magickwand, PixelSetRed);
+  LOAD_DLL_FN (magickwand, PixelSetGreen);
+  LOAD_DLL_FN (magickwand, PixelSetBlue);
+  LOAD_DLL_FN (magickwand, PixelSyncIterator);
+
+  LOAD_DLL_FN (magickcore, DestroyExceptionInfo);
+  LOAD_DLL_FN (magickcore, DestroyString);
+  LOAD_DLL_FN (magickcore, AcquireExceptionInfo);
+  LOAD_DLL_FN (magickcore, GetMagickList);
+
+  return 1;
+}
+
+#undef CloneMagickWand
+#undef DestroyMagickWand
+#undef DestroyPixelIterator
+#undef DestroyPixelWand
+#undef MagickCropImage
+#undef MagickExportImagePixels
+#undef MagickGetException
+#undef MagickGetImage
+#undef MagickGetImageDelay
+#undef MagickGetImageDispose
+#undef MagickGetImageHeight
+#undef MagickGetImagePage
+#undef MagickGetImageSignature
+#undef MagickGetImageWidth
+#undef MagickGetNumberImages
+#undef MagickMergeImageLayers
+#undef MagickFlattenImages
+#undef MagickReadImage
+#undef MagickReadImageBlob
+#undef MagickRelinquishMemory
+#undef MagickRotateImage
+#undef MagickScaleImage
+#undef MagickSetFilename
+#undef MagickSetImageBackgroundColor
+#undef MagickSetIteratorIndex
+#undef MagickWandGenesis
+#undef MagickWandTerminus
+#undef NewMagickWand
+#undef NewPixelIterator
+#undef NewPixelWand
+#undef PixelGetAlpha
+#undef PixelGetMagickColor
+#undef PixelGetNextIteratorRow
+#undef PixelSetIteratorRow
+#undef PixelSetPixelColor
+#undef PixelSetRed
+#undef PixelSetGreen
+#undef PixelSetBlue
+#undef PixelSyncIterator
+#undef DestroyExceptionInfo
+#undef DestroyString
+#undef AcquireExceptionInfo
+#undef GetMagickList
+
+#define CloneMagickWand fn_CloneMagickWand
+#define DestroyMagickWand fn_DestroyMagickWand
+#define DestroyPixelIterator fn_DestroyPixelIterator
+#define DestroyPixelWand fn_DestroyPixelWand
+#define MagickCropImage fn_MagickCropImage
+#define MagickExportImagePixels fn_MagickExportImagePixels
+#define MagickGetException fn_MagickGetException
+#define MagickGetImage fn_MagickGetImage
+#define MagickGetImageDelay fn_MagickGetImageDelay
+#define MagickGetImageDispose fn_MagickGetImageDispose
+#define MagickGetImageHeight fn_MagickGetImageHeight
+#define MagickGetImagePage fn_MagickGetImagePage
+#define MagickGetImageSignature fn_MagickGetImageSignature
+#define MagickGetImageWidth fn_MagickGetImageWidth
+#define MagickGetNumberImages fn_MagickGetNumberImages
+#define MagickMergeImageLayers fn_MagickMergeImageLayers
+#define MagickFlattenImages fn_MagickFlattenImages
+#define MagickReadImage fn_MagickReadImage
+#define MagickReadImageBlob fn_MagickReadImageBlob
+#define MagickRelinquishMemory fn_MagickRelinquishMemory
+#define MagickRotateImage fn_MagickRotateImage
+#define MagickScaleImage fn_MagickScaleImage
+#define MagickSetFilename fn_MagickSetFilename
+#define MagickSetImageBackgroundColor fn_MagickSetImageBackgroundColor
+#define MagickSetIteratorIndex fn_MagickSetIteratorIndex
+#define MagickWandGenesis fn_MagickWandGenesis
+#define MagickWandTerminus fn_MagickWandTerminus
+#define NewMagickWand fn_NewMagickWand
+#define NewPixelIterator fn_NewPixelIterator
+#define NewPixelWand fn_NewPixelWand
+#define PixelGetAlpha fn_PixelGetAlpha
+#define PixelGetMagickColor fn_PixelGetMagickColor
+#define PixelGetNextIteratorRow fn_PixelGetNextIteratorRow
+#define PixelSetIteratorRow fn_PixelSetIteratorRow
+#define PixelSetPixelColor fn_PixelSetPixelColor
+#define PixelSetRed fn_PixelSetRed
+#define PixelSetGreen fn_PixelSetGreen
+#define PixelSetBlue fn_PixelSetBlue
+#define PixelSyncIterator fn_PixelSyncIterator
+#define DestroyExceptionInfo fn_DestroyExceptionInfo
+#define DestroyString fn_DestroyString
+#define AcquireExceptionInfo fn_AcquireExceptionInfo
+#define GetMagickList fn_GetMagickList
+
+#endif /* !WINDOWSNT */
+
 /* Log ImageMagick error message.
    Useful when a ImageMagick function returns the status `MagickFalse'.  */
 
@@ -8406,7 +8776,7 @@ imagemagick_compute_animated_image (MagickWand *super_wand, int ino)
       PixelWand **source, **dest;
       size_t source_width, source_height;
       ssize_t source_left, source_top;
-      MagickPixelPacket pixel;
+      PixelInfo pixel;
       DisposeType dispose;
       ptrdiff_t lines = 0;
 
@@ -8471,7 +8841,7 @@ imagemagick_compute_animated_image (MagickWand *super_wand, int ino)
               if (dispose == BackgroundDispose || PixelGetAlpha (source[x]))
 		{
                   PixelGetMagickColor (source[x], &pixel);
-		  PixelSetMagickColor (dest[x + source_left], &pixel);
+                  PixelSetPixelColor (dest[x + source_left], &pixel);
 		}
             }
           PixelSyncIterator (dest_iterator);
@@ -8516,7 +8886,7 @@ imagemagick_load_image (struct frame *f, struct image *img,
   MagickWand *image_wand;
   PixelIterator *iterator;
   PixelWand **pixels, *bg_wand = NULL;
-  MagickPixelPacket  pixel;
+  PixelInfo  pixel;
   Lisp_Object image;
   Lisp_Object value;
   Lisp_Object crop;
@@ -8912,6 +9282,11 @@ and `imagemagick-types-inhibit'.  */)
   char **imtypes;
   size_t i;
 
+#if WINDOWSNT
+          if (!init_imagemagick_functions ())
+            return Qnil;
+#endif
+
   ex = AcquireExceptionInfo();
   imtypes = GetMagickList ("*", &numf, ex);
   DestroyExceptionInfo(ex);
@@ -9926,12 +10368,16 @@ non-numeric, there is no explicit limit on the size of images.  */);
 #if defined (HAVE_IMAGEMAGICK)
   DEFSYM (Qimagemagick, "imagemagick");
   ADD_IMAGE_TYPE (Qimagemagick);
+#if defined HAVE_NTGUI && !defined CYGWIN
+  DEFSYM (Qmagickwand, "magickwand");
+  DEFSYM (Qmagickcore, "magickcore");
+#endif /* HAVE_NTGUI */
 #endif
 
 #if defined (HAVE_RSVG)
   DEFSYM (Qsvg, "svg");
   ADD_IMAGE_TYPE (Qsvg);
-#ifdef HAVE_NTGUI
+#if defined (HAVE_NTGUI) && !defined (CYGWIN)
   /* Other libraries used directly by svg code.  */
   DEFSYM (Qgdk_pixbuf, "gdk-pixbuf");
   DEFSYM (Qglib, "glib");

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 21 Jan 2017 21:40:44 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
>  Please describe how this would work, without using
>  dynamic-library-alist.
> 
> But I never said that it would work without using dynamic-library-alist ?

Then it seems we are in violent agreement about this.

This sub-thread started when I said ImageMagick was not supported on
Windows because it could only be linked in statically.  You disagreed
with that, but now it looks like you actually agree, and posted a
patch to add the missing stuff.

> +       '(magickwand "libMagickWand-7.Q16HDRI-0.dll" "libMagickWand-7.Q16-0.dll")
> +       '(magickcore "libMagickCore-7.Q16HDRI-0.dll" "libMagickCore-7.Q16-0.dll")

Does this mean we will only support ImageMagick 7.x and later on
Windows?  If so, the configure-time test should be changed, since it
currently allows 6.x, I think.

> +static bool
> +init_imagemagick_functions (void)
> +{
> +  HMODULE magickwand, magickcore;
> +
> +  if (!(magickcore = w32_delayed_load (Qmagickcore))
> +      || !(magickwand = w32_delayed_load (Qmagickwand)))
> +    return 0;

Are these 2 DLLs completely independent?  Or will loading one of them
automatically load the other, due to dependencies?

> @@ -8406,7 +8776,7 @@ imagemagick_compute_animated_image (MagickWand *super_wand, int ino)
>        PixelWand **source, **dest;
>        size_t source_width, source_height;
>        ssize_t source_left, source_top;
> -      MagickPixelPacket pixel;
> +      PixelInfo pixel;

What is this about?

> +#if defined HAVE_NTGUI && !defined CYGWIN

A.k.a. "#ifdef WINDOWSNT".

Thanks.

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-22 17:50 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sat, 21 Jan 2017 21:40:44 +0100
> > Cc: Juanma Barranquero <lekktu@gmail.com>, Óscar Fuentes <ofv@wanadoo.es
> >,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> >  Please describe how this would work, without using
> >  dynamic-library-alist.
> >
> > But I never said that it would work without using dynamic-library-alist ?
>
> Then it seems we are in violent agreement about this.
>
> This sub-thread started when I said ImageMagick was not supported on
> Windows because it could only be linked in statically.  You disagreed
> with that, but now it looks like you actually agree, and posted a
> patch to add the missing stuff.
>
> > +       '(magickwand "libMagickWand-7.Q16HDRI-0.dll"
> "libMagickWand-7.Q16-0.dll")
> > +       '(magickcore "libMagickCore-7.Q16HDRI-0.dll"
> "libMagickCore-7.Q16-0.dll")
>
>
Does this mean we will only support ImageMagick 7.x and later on
> Windows?  If so, the configure-time test should be changed, since it
> currently allows 6.x, I think.
>

Given that MSYS2 itself has switched to IM7, I don't see the point to keep
support forIM6.


> > +static bool
> > +init_imagemagick_functions (void)
> > +{
> > +  HMODULE magickwand, magickcore;
> > +
> > +  if (!(magickcore = w32_delayed_load (Qmagickcore))
> > +      || !(magickwand = w32_delayed_load (Qmagickwand)))
> > +    return 0;
>
> Are these 2 DLLs completely independent?  Or will loading one of them
> automatically load the other, due to dependencies?
>
>
Actually, it seems that magickwand depends on magickcore.
However, you may need later on a handle on both dlls to catch the functions
each one holds.



> > @@ -8406,7 +8776,7 @@ imagemagick_compute_animated_image (MagickWand
> *super_wand, int ino)
> >        PixelWand **source, **dest;
> >        size_t source_width, source_height;
> >        ssize_t source_left, source_top;
> > -      MagickPixelPacket pixel;
> > +      PixelInfo pixel;
>
> What is this about?
>
>
AFAIR they changed the names of a few structures.


> > +#if defined HAVE_NTGUI && !defined CYGWIN
>
> A.k.a. "#ifdef WINDOWSNT".
>
>
Ok.

Fabrice

[-- Attachment #2: Type: text/html, Size: 3944 bytes --]

Re: 64-bit build on Windows

[Paul Eggert]

Fabrice Popineau wrote:
> Given that MSYS2 itself has switched to IM7, I don't see the point to keep
> support for IM6.

My vague impression is that ImageMagick 7 is still too buggy on GNU/Linux to be 
useful for Emacs there. Is my impression incorrect? Even if I'm wrong, Emacs 
should continue to support IM6 for a while on non-MS-Windows platforms, to 
support users who don't have IM7 installed yet.

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-22 22:22 GMT+01:00 Paul Eggert <eggert@cs.ucla.edu>:

> Fabrice Popineau wrote:
>
>> Given that MSYS2 itself has switched to IM7, I don't see the point to keep
>> support for IM6.
>>
>
> My vague impression is that ImageMagick 7 is still too buggy on GNU/Linux
> to be useful for Emacs there. Is my impression incorrect? Even if I'm
> wrong, Emacs should continue to support IM6 for a while on non-MS-Windows
> platforms, to support users who don't have IM7 installed yet.
>

I agree for those platforms which have a choice. With MSYS2, there is not
much choice.

[-- Attachment #2: Type: text/html, Size: 1053 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>  Juanma Barranquero <lekktu@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 22 Jan 2017 13:22:48 -0800
> 
> Fabrice Popineau wrote:
> > Given that MSYS2 itself has switched to IM7, I don't see the point to keep
> > support for IM6.
> 
> My vague impression is that ImageMagick 7 is still too buggy on GNU/Linux to be 
> useful for Emacs there. Is my impression incorrect? Even if I'm wrong, Emacs 
> should continue to support IM6 for a while on non-MS-Windows platforms, to 
> support users who don't have IM7 installed yet.

I agree.

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 22 Jan 2017 21:38:39 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
>  > + '(magickwand "libMagickWand-7.Q16HDRI-0.dll" "libMagickWand-7.Q16-0.dll")
>  > + '(magickcore "libMagickCore-7.Q16HDRI-0.dll" "libMagickCore-7.Q16-0.dll")
> 
>  Does this mean we will only support ImageMagick 7.x and later on
>  Windows? If so, the configure-time test should be changed, since it
>  currently allows 6.x, I think.
> 
> Given that MSYS2 itself has switched to IM7, I don't see the point to keep support forIM6.

But ImageMagick libraries were available as DLLs regardless of what
MSYS2 did or didn't do, so I think we should have associations for
those binaries as well, for ImageMagick 6.x.

>  > @@ -8406,7 +8776,7 @@ imagemagick_compute_animated_image (MagickWand *super_wand, int
>  ino)
>  > PixelWand **source, **dest;
>  > size_t source_width, source_height;
>  > ssize_t source_left, source_top;
>  > - MagickPixelPacket pixel;
>  > + PixelInfo pixel;
> 
>  What is this about?
> 
> AFAIR they changed the names of a few structures.

Then this should be conditioned on ImageMagick version, and we
probably need a Lisp variable holding the version number to look for
DLLs that are specific to the version against which Emacs was
compiled, similar to libpng-version.

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Fri, Jan 20, 2017 at 4:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> There's no problem when Imagemagick is absent.  The --without-*
> switches are only needed when the package is present, but you want to
> override its automatic detection.
>
> AFAIR, the problem with Imagemagick support on Windows is that it can
> only be supported when linked in statically, so the produced binary
> can only be safely used on the system where it was built.  And on top
> of that, there's a problem with Imagemagick 7.x, which I think is not
> specific to Windows.

I think there are two issues here. One is what to do (and explain) when
ImageMagick is present. As you say,

> You see, w32-win.el doesn't have ImageMagick-related DLL names in its
> value of dynamic-library-alist, and without that Emacs won't know
> which libraries to look for when ImageMagick support is requested.
>
> That alist is how officially supported optional libraries should be
> introduced into the Windows build of Emacs -- we want a binary that
> was built with these libraries to be able to run on systems without
> the DLLs being available.  By contrast, just linking with the -lLIB
> link-time switch produces a binary that will refuse to load if the DLL
> is not found.

That's entirely correct and we will want to modify ImageMagick support on
Windows as we did with other image libraries and GnuTLS and libxml.

But I am now worried about nt/INSTALL.W64, which is directed to those who
want to build the 64-bit port anew, from scratch (from the repository or a
source tarball). Following that file's steps, Imagemagick is not installed.
I think that anyone knowledgeable enough to install Imagemagick and try to
build with it will know to use --without-imagemagick if needed. So, I think
the following minimal patch best reflects the current experience:


diff --git a/nt/INSTALL.W64 b/nt/INSTALL.W64
index a12b7fc..1b2bf72 100644
--- a/nt/INSTALL.W64
+++ b/nt/INSTALL.W64
@@ -125,8 +125,8 @@ Now you're ready to build and install Emacs with
autogen, configure, make,
 and make install.

 First we need to switch to the MinGW-w64 environment.  Exit the MSYS2 BASH
-console and run mingw64_shell.bat in the C:\msys64 folder, then cd back to
-your Emacs source directory, e.g.:
+console and run mingw64.exe in the C:\msys64 folder, then cd back to your
+Emacs source directory, e.g.:

   cd /c/emacs/emacs-25

@@ -149,12 +149,9 @@ which 'make install' will use - in this example we set
it to C:\emacs\emacs-25.
 If a prefix is not specified the files will be put in the standard Unix
 directories located in your C:\msys64 directory, but this is not
recommended.

-Note also that we need to disable Imagemagick because Emacs does not yet
-support it on Windows.
-
-  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
   ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick

+
 ** Run make

 This will compile Emacs and build the executables, putting them in the src
warning: LF will be replaced by CRLF in nt/INSTALL.W64.
The file will have its original line endings in your working directory.

[-- Attachment #2: Type: text/html, Size: 3448 bytes --]

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 21 Jan 2017 19:57:01 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> But I am now worried about nt/INSTALL.W64, which is directed to those who want to build the 64-bit port
> anew, from scratch (from the repository or a source tarball). Following that file's steps, Imagemagick is not
> installed. I think that anyone knowledgeable enough to install Imagemagick and try to build with it will know to
> use --without-imagemagick if needed. So, I think the following minimal patch best reflects the current
> experience:

Fine with me, but please wait for a few days to give MinGW64 users a
chance to comment on this.

Thanks.

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Sat, Jan 21, 2017 at 8:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Fine with me, but please wait for a few days to give MinGW64 users a
> chance to comment on this.

No hurry at all.

[-- Attachment #2: Type: text/html, Size: 293 bytes --]

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Sat, Jan 21, 2017 at 8:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> but please wait for a few days to give MinGW64 users a
> chance to comment on this.

One question for them, then. Could it be that I have mingw(32|64).exe
instead of mingw(32|64)_shell.bat because I followed the advice at
http://msys2.github.io/ and did a post-installation update with

  pacman -Sy pacman
  pacman -Syu
  pacman -Su

? If so, it's this something we should recommend in nt/INSTALL.W64?

[-- Attachment #2: Type: text/html, Size: 672 bytes --]

Re: 64-bit build on Windows

[Nikolay Kudryavtsev]

Actually yes, bats were faced out since 2016-07-02 msys2 release, so the 
instructions should probably changed reflect that.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: 64-bit build on Windows

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Jan 21, 2017 at 8:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> but please wait for a few days to give MinGW64 users a
>> chance to comment on this.
>
> One question for them, then. Could it be that I have mingw(32|64).exe
> instead of mingw(32|64)_shell.bat because I followed the advice at
> http://msys2.github.io/ and did a post-installation update with
>
>   pacman -Sy pacman
>   pacman -Syu
>   pacman -Su
>
> ?

Most likely. The method for starting the shell with the specific
settings for each mode (msys2/mingw64/mingw32) changed some months ago.

> If so, it's this something we should recommend in nt/INSTALL.W64?

Nowadays a simple `pacman -Suy' should do the right thing. And IMO using
the updated binary packages is a good thing. (Although the Emacs
problems with ImageMagick started when MSYS2 upgraded to version 7 soon
after it was released. Those are the risks of being `cutting edge'. Arch
and Debian Unstable still are at version 6.9).

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
> Date: Sat, 21 Jan 2017 23:43:50 +0100
> 
> > One question for them, then. Could it be that I have mingw(32|64).exe
> > instead of mingw(32|64)_shell.bat because I followed the advice at
> > http://msys2.github.io/ and did a post-installation update with
> >
> >   pacman -Sy pacman
> >   pacman -Syu
> >   pacman -Su
> >
> > ?
> 
> Most likely. The method for starting the shell with the specific
> settings for each mode (msys2/mingw64/mingw32) changed some months ago.
> 
> > If so, it's this something we should recommend in nt/INSTALL.W64?
> 
> Nowadays a simple `pacman -Suy' should do the right thing. And IMO using
> the updated binary packages is a good thing.

If this change in MSYS2 is only a few months old, I think we should
mention both possibilities in the instructions, in case the reader has
an older installation.

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Sat, Jan 21, 2017 at 7:57 PM, Juanma Barranquero <lekktu@gmail.com>
wrote:

> -  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
>    ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick

     ./configure --prefix=/c/emacs/emacs-25

I meant, of course.

[-- Attachment #2: Type: text/html, Size: 411 bytes --]

Re: 64-bit build on Windows

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Jan 21, 2017 at 7:57 PM, Juanma Barranquero <lekktu@gmail.com>
> wrote:
>
>> -  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
>>    ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick
>
>      ./configure --prefix=/c/emacs/emacs-25
>
> I meant, of course.

I'm a mingw64bit user.

It's been a while since I installed msys/mingw64, so I may be out of
date.

I have no imagemagick installed in msys2, so it was (is?) not installed
by default (I'd be surprised if it is).

I suggest nt/INSTALL.w64 include instructions for installing Imagemagick,
and any other optional packages that can be installed from msys2 at this
time. And also a list of optional packages that must be gotten
elsewhere.

That way users following all the instructions get as complete an Emacs
as possible, and users wanting a smaller install can leave things out.

Currently, the list of packages to get from pacman lists some optional
packages, but not all, so the statement "you now have a complete build
environment for emacs" is misleading.

At the very least, there should somewhere be a _complete_ list of
optional packages; INSTALL.w64 could reference that list, rather than
repeat it.


One more point; under "run configure", it says installing Emacs to the
default "C:\msys64" is "not recommended". Why not?

If it's because there is an msys package that installs Emacs there, say
so. People need information to make informed choices.

-- 
-- Stephe

Re: 64-bit build on Windows

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 22 Jan 2017 11:50:59 -0600
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> I suggest nt/INSTALL.w64 include instructions for installing Imagemagick,
> and any other optional packages that can be installed from msys2 at this
> time. And also a list of optional packages that must be gotten
> elsewhere.

It already does:

  ** Download and install the necessary packages

  Run msys2_shell.bat in your MSYS2 directory and you will see a BASH window
  opened.

  In the BASH prompt, use the following command to install the necessary
  packages (you can copy and paste it into the shell with Shift + Insert):

    pacman -S base-devel \
    mingw-w64-x86_64-toolchain \
    mingw-w64-x86_64-xpm-nox \
    mingw-w64-x86_64-libtiff \
    mingw-w64-x86_64-giflib \
    mingw-w64-x86_64-libpng \
    mingw-w64-x86_64-libjpeg-turbo \
    mingw-w64-x86_64-librsvg \
    mingw-w64-x86_64-libxml2 \
    mingw-w64-x86_64-gnutls \
    mingw-w64-x86_64-zlib

  The packages include the base developer tools (autoconf, automake, grep, make,
  etc.), the compiler toolchain (gcc, gdb, etc.), several image libraries, an
  XML library, the GnuTLS (transport layer security) library, and zlib for
  decompressing text.  Only the first three packages are required (base-devel,
  toolchain, xpm-nox); the rest are optional.  You can select only part of the
  libraries if you don't need them all.

ImageMagick is not listed because the Windows build doesn't support it
yet.  All the other packages are (or should be) listed; if you think
something is missing, or the text below the list is unclear about
what's optional, please point out what should be
added/removed/modified.

> Currently, the list of packages to get from pacman lists some optional
> packages, but not all, so the statement "you now have a complete build
> environment for emacs" is misleading.

It is not meant to be misleading, it is meant to list everything.  And
I think it does.

> At the very least, there should somewhere be a _complete_ list of
> optional packages; INSTALL.w64 could reference that list, rather than
> repeat it.

The above is that complete list.

> One more point; under "run configure", it says installing Emacs to the
> default "C:\msys64" is "not recommended". Why not?

I don't know.  I suggest to ask the author.

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-22 19:07 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

>
> ImageMagick is not listed because the Windows build doesn't support it
> yet.  All the other packages are (or should be) listed; if you think
> something is missing, or the text below the list is unclear about
> what's optional, please point out what should be
> added/removed/modified.
>

IIRC dbus should be disabled for Windows. Last time I tried it, it was of
no use under Windows.
Also, at the moment, `make check' checks dbus even if it was disabled when
compiling.

Fabrice

[-- Attachment #2: Type: text/html, Size: 935 bytes --]

Re: 64-bit build on Windows

[Juanma Barranquero]

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

On Fri, Jan 20, 2017 at 3:32 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> FWIW I build Emacs on MSYS2 and --without-imagemagick seems unnecessary.
> The configure script just says that Imagemagick is absent.

Indeed, I just built trunk and emacs-25 from inside mingw64.exe without
specifying either --without-imagemagick or PKG_CONFIG_PATH, just with
./configure --prefix=`pwd`, and it went perfectly well.

> I have no idea about PKG_CONFIG_PATH. The MSYS2 recipe does not mention
> it and seems to work just fine.

Our instructions in nt/INSTALL.W64 do not talk about pkg-config, but they
show PKG_CONFIG_PATH used with configure:

  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
  ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick

[-- Attachment #2: Type: text/html, Size: 960 bytes --]

Re: 64-bit build on Windows

[Arash Esbati]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jan 20, 2017 at 3:32 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> I have no idea about PKG_CONFIG_PATH. The MSYS2 recipe does not mention
>> it and seems to work just fine.
>
> Our instructions in nt/INSTALL.W64 do not talk about pkg-config, but they
> show PKG_CONFIG_PATH used with configure:
>
>   PKG_CONFIG_PATH=/mingw64/lib/pkgconfig \
>   ./configure --prefix=/c/emacs/emacs-25 --without-imagemagick

I think it is safe to drop the line with pkg-config as Msys2 does the
right thing here.  In file /etc/profile, you find these lines
(unnecessary ones snipped):

source '/etc/msystem'
case "${MSYSTEM}" in
MINGW32)
  MINGW_MOUNT_POINT="${MINGW_PREFIX}"
  PKG_CONFIG_PATH="${MINGW_MOUNT_POINT}/lib/pkgconfig:${MINGW_MOUNT_POINT}/share/pkgconfig"
  ;;
MINGW64)
  MINGW_MOUNT_POINT="${MINGW_PREFIX}"
  PKG_CONFIG_PATH="${MINGW_MOUNT_POINT}/lib/pkgconfig:${MINGW_MOUNT_POINT}/share/pkgconfig"
  ;;
*)
  PKG_CONFIG_PATH="/usr/lib/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig"
esac

${MINGW_PREFIX} is set in /etc/msystem to /mingw32 or /mingw64.

I would suggest to put a line there saying that Dbus should be disabled
on Windows.  There was a bug report for AUCTeX where a .tex file could
not be opened because Emacs was compiled without disabling Dbus.[1,2]

Best, Arash

Footnotes: 
[1]  http://lists.gnu.org/archive/html/bug-auctex/2016-09/msg00008.html

[2]  https://sourceforge.net/p/emacsbinw64/discussion/general/thread/87c80d2f/

Re: 64-bit build on Windows

[Fabrice Popineau]

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

2017-01-26 20:05 GMT+01:00 Arash Esbati <arash@gnu.org>:

> I would suggest to put a line there saying that Dbus should be disabled
> on Windows.  There was a bug report for AUCTeX where a .tex file could
> not be opened because Emacs was compiled without disabling Dbus.[1,2]
>
>
IMHO dbus should be disabled in configure script for MSYS2.
The problem is that it gets detected, selected, compiled without errors.
But Emacs sources are missing some pieces to make it functional
(add_read_fd,
add_write_fd).

Fabrice

[-- Attachment #2: Type: text/html, Size: 912 bytes --]

Re: 64-bit build on Windows

[Angelo Graziosi]

Fabrice Popineau wrote:
> The attached patch should be a proof of concept.

> master-imagemagick.diff
> Description: Text document

I tried to use those patches to build Emacs master but they do not apply 
cleanly to current master:

MINGW_INSTALLS=mingw64 makepkg-mingw -sLf
[...]
==> Avvio di prepare() in corso...
patching file configure.ac
patching file lisp/loadup.el
patching file lisp/term/w32-win.el
Hunk #1 succeeded at 271 with fuzz 2.
patching file src/image.c
Hunk #1 FAILED at 2307.
Hunk #2 FAILED at 8244.
Hunk #4 FAILED at 8471.
Hunk #6 FAILED at 8912.
4 out of 7 hunks FAILED -- saving rejects to file src/image.c.rej
==> ERRORE: Si è verificato un errore in prepare().
     L'operazione sta per essere interrotta...

Now I haven't time to see the reasons... May you?

TIA,
   Angelo.