bug#18302: MSYS2 build issues

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Aug 2014 00:32:41 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> 
> I do MSYS2-MinGW64 Emacs trunk builds with the simple steps:
> 
> ./autogen.sh
> 
> ./configure --prefix=/Emacs.app --with-wide-int 
> --build=x86_64-w64-mingw32 --without-imagemagick 
> 'CFLAGS=-I/mingw64/include/noX -Ofast -g0 -pipe' LDFLAGS=-pipe
> 
> make...
> 
> 
> The build needs the
> 
>    CFLAGS=-I/mingw64/include/noX
> 
> definition because of the manner how MSYS2 work. It puts all the stuffs 
> depending on msys2*dll (the equivalent of cygwin1.dll) under /usr. 
> Instead the MinGW34 and MinGW64 applications are under /mingw32 and 
> /mingw64 respectively. Usually, to work with MinGW64 applications, one 
> needs to start the shell-console with mingw64_shell.bat batch file 
> (msys2_shell.bat or mingw32_shell.bat to work with MSYS2 or MinGW32 apps).

Sorry, I don't understand what does this have to do with the issue at
hand.  You are talking about how MSYS2 maps the Posix-like /mingw32
and /mingw64 trees into Windows filesystems.  Fine; but why does this
matter in the context of this discussion?  ISTM that if you want to be
able to produce both MinGW32 and MinGW64 programs on the same machine,
you need 2 separate hierarchies anyway, one for the 32-bit and the
other for 64-bit programs.  IOW, just copy the /usr/include tree into
each of the mingwXX parents, and each respective compiler will find
them automatically, because it always searches for ../include relative
to its binary (you can see that with "gcc -v").  If that doesn't work,
then set C_INCLUDE_PATH in the environment to point to the right
include directory in each case.

Without having this set up correctly, your development environment is
subtly broken.

And if MSYS2 somehow makes this hard or impossible, then it's an MSYS2
bug that should be fixed ASAP.

> So, it is in the "nature" of MSYS2 that it puts things in non-standard 
> directory for MinGW32/64 apps. Probably one can change Emacs configure 
> to avoid these issue but I wonder, given the simple workaround shown 
> above, if this is worth the effort.

As I explained in this discussion, this has nothing to do with Emacs.

No, this is a basic compiler configuration issue: the headers should
be in a place where the compiler can find them, period.  No additional
"-I" switches should be needed to allow the compiler to find the
headers (and the library files) of an installed library/package.

> Instead, it would interesting, to understand why removing the configure 
> option, "--without-imagemagick", with the MinGW64 ImageMagick package 
> installed, configure enables imagemagick support but the build fails 
> with a linker error.. but this is matter for another thread.. I think.

The Windows build currently doesn't support ImageMagick.  That's why
you see those failures.  Patches are welcome to add ImageMagick
support in the same way we support other image libraries on Windows:
i.e. via dynamic load at run time if the library exists and when it is
first used.  See image.c for the details.