GNU bug report logs - #18302
MSYS2 build issues

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18302 in the body.
You can then email your comments to 18302 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Chris Zheng <chriszheng99 <at> gmail.com>
Subject: MSYS2 build issues
Date: Wed, 20 Aug 2014 11:54:53 +0200

[Message part 1 (text/plain, inline)]

Dear Emacs maintainers,

thanks to the work of Chris Zheng and Eli Zaretskii we can build Emacs
on MSYS2 with MinGW-w64.  However, the process is not completely
painless: xpm support needs manual tweaking of CFLAGS, configure
script must be run with special flags, and make sometimes crashes for
the "emacs$(EXEEXT)" target.

I am submitting my proposed fixes for these three issues (based on the
latest trunk version of Emacs).  With this fix I can successfully
compile 64-bit Emacs using MSYS2 and MinGW-w64 with automatic xpm
support, and the process follows the same easy steps as described in
nt/INSTALL (just running ./autogen.sh, ./configure --prefix=..., and
make).  I intend to submit some additional MSYS2+MinGW-w64
documentation (file nt/INSTALL) should this patch be accepted.

Best regards,

Karol

[configure.ac (application/octet-stream, attachment)]

[Makefile.in (application/octet-stream, attachment)]

Message #8 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
Cc: chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Wed, 20 Aug 2014 19:26:16 +0300

> Date: Wed, 20 Aug 2014 11:54:53 +0200
> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
> Cc: Chris Zheng <chriszheng99 <at> gmail.com>
> 
> thanks to the work of Chris Zheng and Eli Zaretskii we can build Emacs
> on MSYS2 with MinGW-w64.  However, the process is not completely
> painless: xpm support needs manual tweaking of CFLAGS, configure
> script must be run with special flags, and make sometimes crashes for
> the "emacs$(EXEEXT)" target.

What do you mean by "make crashes"?  Can you show some messages or
other evidence of these crashes?

> I am submitting my proposed fixes for these three issues (based on the
> latest trunk version of Emacs).  With this fix I can successfully
> compile 64-bit Emacs using MSYS2 and MinGW-w64 with automatic xpm
> support, and the process follows the same easy steps as described in
> nt/INSTALL (just running ./autogen.sh, ./configure --prefix=..., and
> make).  I intend to submit some additional MSYS2+MinGW-w64
> documentation (file nt/INSTALL) should this patch be accepted.

Thanks.

First, I don't see your name on file with the FSF copyright
assignments.  Without that, we will be unable to accept substantial
contributions such as this one.  Would you be willing to sign the
necessary legal papers (assuming you are the sole author of these
changes)?

I have a few questions/comments about your suggested changes.  (In the
future, please always send diffs obtained by "bzr diff" or "diff -u",
not entire files.)

> -      *-mingw32 )
> -		opsys=mingw32
> +      *-mingw* )
> +		opsys=mingw

This change from "mingw32" to "mingw" causes a lot of changes all
over.  is it really necessary?  Is there a problem to call the system
"mingw32"?  It's just a value of a variable, with no other meaning.

Without changing "mingw32" to "mingw", the changes are small enough to
not require legal papers (but you might need them anyway further down
the road, if you intend to submit more patches).

> -if test "$opsys" = "mingw32"; then
> -  case "$canonical" in
> -    x86_64-*-mingw32) C_SWITCH_SYSTEM="-mtune=generic" ;;
> -    *) C_SWITCH_SYSTEM="-mtune=pentium4" ;;
> -  esac
> +if test "$opsys" = "mingw"; then
> +  C_SWITCH_SYSTEM="-mtune=generic"

Why do you want to change the -mtune switch for the 32-bit build?  It
is by default configured to Pentium 4 so that the resulting binary
could run on Windows 9X, which we still support.  Users that want to
produce binaries tuned to more modern CPUs for their own consumption
can always do that by asking for custom CFLAGS.

>  ### slightly different requirements wrt image libraries (it doesn't
>  ### use -lXpm because it loads the xpm shared library dynamically at
>  ### run time).
> -if test "${opsys}" = "mingw32"; then
> +if test "${opsys}" = "mingw"; then
>    if test "${with_xpm}" != "no"; then
> +    CPPFLAGS="$CPPFLAGS -I/mingw64/include/noX"
>      AC_CHECK_HEADER(X11/xpm.h, HAVE_XPM=yes, HAVE_XPM=no, [

Why do you need to add this switch to CPPFLAGS?  Why cannot the XPM
header files be installed in the default include tree?

> @@ -435,8 +435,7 @@
>  	else \
>  	  LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump || exit 1; \
>  	  test "X$(PAXCTL)" = X || $(PAXCTL) -zex emacs$(EXEEXT); \
> -	  rm -f bootstrap-emacs$(EXEEXT); \
> -	  ln emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
> +	  ln -vf emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
>  	fi

This is a general (not MinGW-specific) part of src/Makefile.in, so I'm
not sure we should be changing it.  In particular, I'm not sure
non-GNU 'ln' supports these 2 switches (and why do you need -v
anyway?).

Also, I don't understand why this solves anything.  If "rm -f" fails,
presumably because bootstrap-emacs.exe is still running, so will, or
might, "ln -f".  And the failure is not fatal: just type "make" again,
and it runs to completion.

Thanks again for working on this.

Message #11 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>, chriszheng99 <at> gmail.com,
 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Wed, 20 Aug 2014 13:04:44 -0400

Eli Zaretskii wrote:

> not sure we should be changing it.  In particular, I'm not sure
> non-GNU 'ln' supports these 2 switches (and why do you need -v
> anyway?).

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html

   "Don't rely on ln having a -f option."

This and other changes that you commented on give the strong impression
that this patch contains a bunch of things that are just personal
preferences.

Message #14 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Wed, 20 Aug 2014 20:20:08 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>,  chriszheng99 <at> gmail.com,  18302 <at> debbugs.gnu.org
> Date: Wed, 20 Aug 2014 13:04:44 -0400
> 
> Eli Zaretskii wrote:
> 
> > not sure we should be changing it.  In particular, I'm not sure
> > non-GNU 'ln' supports these 2 switches (and why do you need -v
> > anyway?).
> 
> http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html
> 
>    "Don't rely on ln having a -f option."

Thanks, that's what I remembered.

> This and other changes that you commented on give the strong impression
> that this patch contains a bunch of things that are just personal
> preferences.

The only real issue AFAICT is the value that MSYS2's 'uname' returns,
that issue does need a (trivial) solution.

Message #17 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, Chris Zheng <chriszheng99 <at> gmail.com>,
 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 12:08:08 +0200

Hello all,

thank you for the very quick response.  First, I am sorry for some of
the mess, like submitting whole files.  Now to the technical stuff:

1. I am the sole author of these changes.  I have no issue with
signing the required legal papers.  Please, let me know how to proceed
with this.

2. MSYS2 'uname' is indeed the main source of the problem.  My
solution fixes that, and also renames opsys=mingw32 to opsys=mingw.
This renaming is not strictly necessary, but I believe it is a good
practice to name things as clearly as possible.  In this case, the
name mingw32 seems too related to a 32-bit system, which it is not any
more after my changes.

3. "-mtune" change: I don't see how Pentium4 optimisations are related
to running Windows9X.  I know people still running Windows95 on
Pentium III.  Shouldn't the official Emacs build be as generic as
possible?  Perhaps one should even take away the whole -mtune part for
MinGW.

4. CPPFLAGS for XPM change follows the same pattern as cygwin.  Both
cygwin and MSYS2 install the XPM library in an unusual place.  Since
adding an include path for cygwin was already accepted, I did not see
any issue with adding a similar solution for MSYS2.

5. I am sorry I was not aware of the ln flag issues.  The -v was only
to see the result and it is completely unnecessary, while the -f was
needed just as it was used for "rm -f" in the original.  The crash is
quite random, and currently I am unable to reproduce it.  Yesterday it
was relatively easy to reproduce, but today it is not happening.
However, I remember that make stopped with something like: unable to
build emacs.exe on line 603 of src/Makefile with reason "rm: cannot
remove ‘bootstrap-emacs.exe’: Device or resource busy".  The crash
happened even when running make without a j flag, that is non-parallel
build.

The easy manual workaround is to just start make again, but then it is
hard to add emacs to any automated build system (for example as an
MSYS2 package).

Given how random this crash is it is hard to justify any change to the
Makefile.in until I or someone else can find the root cause.

Best regards,

Karol

On 20 August 2014 19:20, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Glenn Morris <rgm <at> gnu.org>
>> Cc: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>,  chriszheng99 <at> gmail.com,  18302 <at> debbugs.gnu.org
>> Date: Wed, 20 Aug 2014 13:04:44 -0400
>>
>> Eli Zaretskii wrote:
>>
>> > not sure we should be changing it.  In particular, I'm not sure
>> > non-GNU 'ln' supports these 2 switches (and why do you need -v
>> > anyway?).
>>
>> http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html
>>
>>    "Don't rely on ln having a -f option."
>
> Thanks, that's what I remembered.
>
>> This and other changes that you commented on give the strong impression
>> that this patch contains a bunch of things that are just personal
>> preferences.
>
> The only real issue AFAICT is the value that MSYS2's 'uname' returns,
> that issue does need a (trivial) solution.

Message #20 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
Cc: rgm <at> gnu.org, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 17:30:59 +0300

> Date: Thu, 21 Aug 2014 12:08:08 +0200
> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
> Cc: Glenn Morris <rgm <at> gnu.org>, Chris Zheng <chriszheng99 <at> gmail.com>, 18302 <at> debbugs.gnu.org
> 
> 1. I am the sole author of these changes.  I have no issue with
> signing the required legal papers.  Please, let me know how to proceed
> with this.

Glenn, could you please send him the papers?

> 2. MSYS2 'uname' is indeed the main source of the problem.  My
> solution fixes that, and also renames opsys=mingw32 to opsys=mingw.
> This renaming is not strictly necessary, but I believe it is a good
> practice to name things as clearly as possible.  In this case, the
> name mingw32 seems too related to a 32-bit system, which it is not any
> more after my changes.

I see no reason to change "mingw32" into something else.  It's just a
string, and doesn't imply anything about the bit-ness of the build.
In fact, users who build Emacs will never see this string.  Besides,
MinGW64 tools can also be used to build a 32-bit Emacs.

So let's leave that part alone.

> 3. "-mtune" change: I don't see how Pentium4 optimisations are related
> to running Windows9X.  I know people still running Windows95 on
> Pentium III.

"-mtune=pentium4" does not mean that Pentium III is not supported.  It
just means the code is tuned better for Pentium 4.

Without this switch, newer versions of GCC will use -mtune=native,
which is certainly bad news for users of much older CPUs.

> Shouldn't the official Emacs build be as generic as possible?

Hard to answer that without knowing what you mean by "generic" in this
context.

Again, users who want to build Emacs only for themselves can always
specify -mtune=native at configure time.

> Perhaps one should even take away the whole -mtune part for MinGW.

See above: it is there for a reason.

Note that the 64-build already uses -mtune=generic, because it is free
from the need to support Windows 9X.

> 4. CPPFLAGS for XPM change follows the same pattern as cygwin.  Both
> cygwin and MSYS2 install the XPM library in an unusual place.  Since
> adding an include path for cygwin was already accepted, I did not see
> any issue with adding a similar solution for MSYS2.

IMO, it is a mistake in the Cygwin case as well.  These issues should
be resolved in the compiler installation, not in packages.  If the
user installs xpm (or any other library) she should either install its
headers and library files in the standard places, or configure the
compiler to look in the non-standard places (e.g., by setting
C_INCLUDE_PATH in the environment).  Otherwise, your build environment
is not really 100% functional.

I'd urge the Cygwin Emacs maintainers to revert that special case, but
that's their call.  For native Windows builds, I certainly object to
introducing this deviation.

> 5. I am sorry I was not aware of the ln flag issues.  The -v was only
> to see the result and it is completely unnecessary, while the -f was
> needed just as it was used for "rm -f" in the original.  The crash is
> quite random, and currently I am unable to reproduce it.  Yesterday it
> was relatively easy to reproduce, but today it is not happening.
> However, I remember that make stopped with something like: unable to
> build emacs.exe on line 603 of src/Makefile with reason "rm: cannot
> remove ‘bootstrap-emacs.exe’: Device or resource busy".  The crash
> happened even when running make without a j flag, that is non-parallel
> build.
> 
> The easy manual workaround is to just start make again, but then it is
> hard to add emacs to any automated build system (for example as an
> MSYS2 package).
> 
> Given how random this crash is it is hard to justify any change to the
> Makefile.in until I or someone else can find the root cause.

I think the root cause is obvious: Windows won't let you delete the
executable file of a running program.  So small timing issues can open
a small window of opportunity for this failure.

How about adding a loop there that attempts to delete the file up to 5
times, say, each time sleeping for 1 second after a failure?  If that
works, it will always succeed on the 1st attempt on Posix hosts, so it
is harmless there.

Message #23 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>, chriszheng99 <at> gmail.com,
 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 12:00:06 -0400

Eli Zaretskii wrote:

> Glenn, could you please send him the papers?

OK, sent off-list, but you (or anyone else) can do that just as easily
as I can. Just send the file /gd/gnuorg/Copyright/request-assign.future
from fencepost.

As explained at
https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
the files are also available in gnulib.

Message #26 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
Cc: chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 14:38:13 -0400

On 8/21/2014 10:30 AM, Eli Zaretskii wrote:
>> 4. CPPFLAGS for XPM change follows the same pattern as cygwin.  Both
>> cygwin and MSYS2 install the XPM library in an unusual place.  Since
>> adding an include path for cygwin was already accepted, I did not see
>> any issue with adding a similar solution for MSYS2.
>
> IMO, it is a mistake in the Cygwin case as well.  These issues should
> be resolved in the compiler installation, not in packages.  If the
> user installs xpm (or any other library) she should either install its
> headers and library files in the standard places, or configure the
> compiler to look in the non-standard places (e.g., by setting
> C_INCLUDE_PATH in the environment).  Otherwise, your build environment
> is not really 100% functional.
>
> I'd urge the Cygwin Emacs maintainers to revert that special case, but
> that's their call.  For native Windows builds, I certainly object to
> introducing this deviation.

The Cygwin situation is not comparable.  The headers are installed in 
the standard places.  But Cygwin provides two versions of xpm.h, one in 
/usr/include/X11 and one in /usr/include/noX.  The Cygwin w32 build 
needs to add -I/usr/include/noX to CPPFLAGS (and -L/usr/lib/noX to 
LDFLAGS) in order to pick up the correct version.

Ken

Message #29 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 22:22:36 +0300

> Date: Thu, 21 Aug 2014 14:38:13 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
> 
> > I'd urge the Cygwin Emacs maintainers to revert that special case, but
> > that's their call.  For native Windows builds, I certainly object to
> > introducing this deviation.
> 
> The Cygwin situation is not comparable.  The headers are installed in 
> the standard places.  But Cygwin provides two versions of xpm.h, one in 
> /usr/include/X11 and one in /usr/include/noX.  The Cygwin w32 build 
> needs to add -I/usr/include/noX to CPPFLAGS (and -L/usr/lib/noX to 
> LDFLAGS) in order to pick up the correct version.

No, the solution is to use

  #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
  #include <noX/xpm.h>
  #else
  #include <xpm.h>
  #endif

The way we work around the problem now will break if someone installs
the standard header files in a place other than /usr/include.

And if you disagree, then at least please put the above explanation in
configure.ac, so that we won't need to have this discussion a year
from now.

Message #32 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kbrown <at> cornell.edu
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 22:33:08 +0300

> Date: Thu, 21 Aug 2014 22:22:36 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
> 
>   #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
>   #include <noX/xpm.h>
>   #else
>   #include <xpm.h>
>   #endif

Sorry, I meant

  #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
  #include <noX/xpm.h>
  #else
  #include <X11/xpm.h>
  #endif

Message #35 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Thu, 21 Aug 2014 17:29:51 -0400

On 8/21/2014 3:22 PM, Eli Zaretskii wrote:
>> Date: Thu, 21 Aug 2014 14:38:13 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
>>
>>> I'd urge the Cygwin Emacs maintainers to revert that special case, but
>>> that's their call.  For native Windows builds, I certainly object to
>>> introducing this deviation.
>>
>> The Cygwin situation is not comparable.  The headers are installed in
>> the standard places.  But Cygwin provides two versions of xpm.h, one in
>> /usr/include/X11 and one in /usr/include/noX.  The Cygwin w32 build
>> needs to add -I/usr/include/noX to CPPFLAGS (and -L/usr/lib/noX to
>> LDFLAGS) in order to pick up the correct version.
>
> No, the solution is to use
>
>    #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
>    #include <noX/xpm.h>
>    #else
>    #include <xpm.h>
>    #endif

I neglected to say that xpm.h in /usr/include/noX is actually a symlink 
to /usr/include/noX/X11/xpm.h.  The code that includes xpm.h (in 
image.c) is '#include "X11/xpm.h"' on all platforms.  For the native 
Windows build and the Cygwin w32 build, this is done conditionally on 
NTGUI, after first defining some macros.  In order for "X11/xpm.h" to 
produce the correct file, the include path has to be set up correctly. 
I really don't want to rewrite all this for no good reason.

> The way we work around the problem now will break if someone installs
> the standard header files in a place other than /usr/include.

In the Cygwin case, I'm not sure what you mean by "someone".  The 
headers are provided by Cygwin packages, and package maintainers are 
supposed to know where to put header files.  In this case the package is 
libXpm-noX-devel.  I can't think of any reason why a future maintainer 
would change the location of the headers; but if that happens, then 
emacs will have to adapt.

> And if you disagree, then at least please put the above explanation in
> configure.ac, so that we won't need to have this discussion a year
> from now.

I don't necessarily disagree; it's just that I don't feel like fixing 
something that isn't broken.  If the relevant code in image.c has to be 
rewritten at some point anyway, we could rethink how to best handle 
xpm.h, but for now I prefer to leave it alone.  I'll add a comment to 
configure.ac on the trunk.

Ken

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Angelo Graziosi <angelo.graziosi <at> alice.it>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 00:32:41 +0200

Just a few comments..

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).

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.

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.

Ken Brown wrote:
> it's just that I don't feel like fixing something that isn't broken.

I concord. Emacs has other kind of problems on Cygwin [*] (see recent 
threads on the Cygwin list). Breaking what is working would compromise 
an already fragile situation.

Ciao,
Angelo.

---
[*] On Cygwin, usually I use as configure:

./configure --prefix=/usr/local/Emacs.app --with-w32 
--build=x86_64-pc-cygwin --with-wide-int 'CFLAGS=-Ofast -g0 -pipe' 
LDFLAGS=-pipe CC=clang

which is very similar to that I use on MSYS2..

Message #41 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 09:10:55 +0300

> Date: Thu, 21 Aug 2014 17:29:51 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
> 
> >    #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
> >    #include <noX/xpm.h>
> >    #else
> >    #include <X11/xpm.h>
> >    #endif
> 
> I neglected to say that xpm.h in /usr/include/noX is actually a symlink 
> to /usr/include/noX/X11/xpm.h.

I don't see how this changes anything.  You could use

  #include <noX/X11/xpm.h>

or you could remain with <noX/xpm.h>, they both will work.

> The code that includes xpm.h (in 
> image.c) is '#include "X11/xpm.h"' on all platforms.  For the native 
> Windows build and the Cygwin w32 build, this is done conditionally on 
> NTGUI, after first defining some macros.  In order for "X11/xpm.h" to 
> produce the correct file, the include path has to be set up correctly. 

That just means we need to re-arrange the #ifdef's a bit differently.
Clearly, not rocket science.

> I really don't want to rewrite all this for no good reason.

As I said, this is your call.  My point is that adding
system-dependent -I switches in configure is not the only way, and IMO
not the best one.

> > The way we work around the problem now will break if someone installs
> > the standard header files in a place other than /usr/include.
> 
> In the Cygwin case, I'm not sure what you mean by "someone".

The end-user, of course.  Posix platforms don't limit end-users in
where they install their header files, and GCC supports that.

> I'll add a comment to configure.ac on the trunk.

Thanks, but why not on the release branch?  A comment cannot possibly
do any harm.

Message #44 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Angelo Graziosi <angelo.graziosi <at> alice.it>
Cc: 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 09:30:19 +0300

> Date: Fri, 22 Aug 2014 00:32:41 +0200
> From: Angelo Graziosi <angelo.graziosi <at> 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.

Message #47 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Angelo Graziosi <angelo.graziosi <at> alice.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 12:55:53 +0200

Il 22/08/2014 08:30, Eli Zaretskii ha scritto:

> Sorry, I don't understand what does this have to do with the issue at
> hand.

Sorry for the noise then.. I have tried to explain (unsuccessfully) why 
MSYS2 doesn't put XPM things in standard directory.. probably I 
misinterpreted the thread..

 Angelo

Message #50 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 09:04:35 -0400

On 8/22/2014 2:10 AM, Eli Zaretskii wrote:
> Thanks, but why not on the release branch?  A comment cannot possibly
> do any harm.

Done, as revision 117454.

Message #53 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Angelo Graziosi <angelo.graziosi <at> alice.it>
Cc: 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 16:25:02 +0300

> Date: Fri, 22 Aug 2014 12:55:53 +0200
> From: Angelo Graziosi <angelo.graziosi <at> alice.it>
> CC: 18302 <at> debbugs.gnu.org
> 
> > Sorry, I don't understand what does this have to do with the issue at
> > hand.
> 
> Sorry for the noise then.. I have tried to explain (unsuccessfully) why 
> MSYS2 doesn't put XPM things in standard directory..

MSYS2 cannot put anything anywhere, it can only map some /foo
directories to certain Windows directories.  But those MSYS2 mappings
do not and cannot change the places where the compiler looks for its
headers.

The user who installs XPM is the one who decides where its headers
will be.  MSYS2 cannot possibly change that.

Message #56 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 16:33:16 +0300

> Date: Fri, 22 Aug 2014 09:04:35 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
> 
> On 8/22/2014 2:10 AM, Eli Zaretskii wrote:
> > Thanks, but why not on the release branch?  A comment cannot possibly
> > do any harm.
> 
> Done, as revision 117454.

Thank you.

Message #59 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Chris Zheng <chriszheng99 <at> gmail.com>, Ken Brown <kbrown <at> cornell.edu>,
 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 16:18:11 +0200

[Message part 1 (text/plain, inline)]

Hello all,

I will try to summarise the situation, and I am attaching my updated
solution proposal for this particular bug:

1. MSYS2 uname must be handled properly, and that is fixed in the new
proposed patch.  I disagree with not renaming opsys from mingw32 to
mingw, since mingw32 string is used in other places in the same file
and it means something else there, which I find possibly confusing.
But this change is not in my new patch.

2. -mtune is back to what it was with a minimal change required for
MSYS2+MinGW-w64 uname handling.

3. Include path for xpm in MSYS2+MinGW-w64 is handled in the same way
as in Cygwin.  Perhaps, the same type of comment as was added for
Cygwin should be added for MSYS2+MinGW-w64.

4. A loop is added in the recipe for emacs.exe to handle
bootstrap-emacs.exe busy problem.

Best regards,

Karol

On 22 August 2014 15:33, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 22 Aug 2014 09:04:35 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: karol.ostrovsky <at> gmail.com, chriszheng99 <at> gmail.com, 18302 <at> debbugs.gnu.org
>>
>> On 8/22/2014 2:10 AM, Eli Zaretskii wrote:
>> > Thanks, but why not on the release branch?  A comment cannot possibly
>> > do any harm.
>>
>> Done, as revision 117454.
>
> Thank you.

[configure.ac.diff (text/plain, attachment)]

[Makefile.in.diff (text/plain, attachment)]

Message #62 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
Cc: chriszheng99 <at> gmail.com, kbrown <at> cornell.edu, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Sat, 23 Aug 2014 11:57:20 +0300

> Date: Fri, 22 Aug 2014 16:18:11 +0200
> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
> Cc: Ken Brown <kbrown <at> cornell.edu>, Chris Zheng <chriszheng99 <at> gmail.com>, 18302 <at> debbugs.gnu.org
> 
> I will try to summarise the situation, and I am attaching my updated
> solution proposal for this particular bug:
> 
> 1. MSYS2 uname must be handled properly, and that is fixed in the new
> proposed patch.  I disagree with not renaming opsys from mingw32 to
> mingw, since mingw32 string is used in other places in the same file
> and it means something else there, which I find possibly confusing.
> But this change is not in my new patch.
> 
> 2. -mtune is back to what it was with a minimal change required for
> MSYS2+MinGW-w64 uname handling.
> 
> 3. Include path for xpm in MSYS2+MinGW-w64 is handled in the same way
> as in Cygwin.  Perhaps, the same type of comment as was added for
> Cygwin should be added for MSYS2+MinGW-w64.
> 
> 4. A loop is added in the recipe for emacs.exe to handle
> bootstrap-emacs.exe busy problem.

Thanks.  I installed items 1, 2, and 4, but not item 3.

If you think we should do something about the xpm.h header, then
please try this alternative solution: copy the xpm.h header file into
the X11 subdirectory of your GCC 'include' directory (the one where
you have all the standard C header files), then try configuring and
building Emacs without adding the "-I/mingw64/include/noX" switch to
CPPFLAGS.  If that doesn't work, please show the error messages you
get from the compiler, and let's take it from there.

If, for some reason, you think that copying xpm.h to include/X11/xpm.h
is not appropriate, please explain why you think so.

Message #65 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Chris Zheng <chriszheng99 <at> gmail.com>, Ken Brown <kbrown <at> cornell.edu>,
 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Mon, 25 Aug 2014 10:18:20 +0200

Hello Eli,

thank you for the help.  As for the item 3: as far as I understand the
situation with xpm in MinGW-w64 is the same as in Cygwin.  There are
two packages providing xpm, and it is the package that is installed in
the non-standard place that must be used for Emacs native Windows
build.  Thus, I don't see why the same solution that was approved for
Cygwin cannot be used for MinGW-w64.

Best regards,

Karol

On 23 August 2014 10:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 22 Aug 2014 16:18:11 +0200
>> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
>> Cc: Ken Brown <kbrown <at> cornell.edu>, Chris Zheng <chriszheng99 <at> gmail.com>, 18302 <at> debbugs.gnu.org
>>
>> I will try to summarise the situation, and I am attaching my updated
>> solution proposal for this particular bug:
>>
>> 1. MSYS2 uname must be handled properly, and that is fixed in the new
>> proposed patch.  I disagree with not renaming opsys from mingw32 to
>> mingw, since mingw32 string is used in other places in the same file
>> and it means something else there, which I find possibly confusing.
>> But this change is not in my new patch.
>>
>> 2. -mtune is back to what it was with a minimal change required for
>> MSYS2+MinGW-w64 uname handling.
>>
>> 3. Include path for xpm in MSYS2+MinGW-w64 is handled in the same way
>> as in Cygwin.  Perhaps, the same type of comment as was added for
>> Cygwin should be added for MSYS2+MinGW-w64.
>>
>> 4. A loop is added in the recipe for emacs.exe to handle
>> bootstrap-emacs.exe busy problem.
>
> Thanks.  I installed items 1, 2, and 4, but not item 3.
>
> If you think we should do something about the xpm.h header, then
> please try this alternative solution: copy the xpm.h header file into
> the X11 subdirectory of your GCC 'include' directory (the one where
> you have all the standard C header files), then try configuring and
> building Emacs without adding the "-I/mingw64/include/noX" switch to
> CPPFLAGS.  If that doesn't work, please show the error messages you
> get from the compiler, and let's take it from there.
>
> If, for some reason, you think that copying xpm.h to include/X11/xpm.h
> is not appropriate, please explain why you think so.

Message #68 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
Cc: chriszheng99 <at> gmail.com, kbrown <at> cornell.edu, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Mon, 25 Aug 2014 17:56:42 +0300

> Date: Mon, 25 Aug 2014 10:18:20 +0200
> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
> Cc: Ken Brown <kbrown <at> cornell.edu>, Chris Zheng <chriszheng99 <at> gmail.com>, 18302 <at> debbugs.gnu.org
> 
> As for the item 3: as far as I understand the
> situation with xpm in MinGW-w64 is the same as in Cygwin.  There are
> two packages providing xpm, and it is the package that is installed in
> the non-standard place that must be used for Emacs native Windows
> build.  Thus, I don't see why the same solution that was approved for
> Cygwin cannot be used for MinGW-w64.

I already said that IMO Cygwin should not add any switches, either.

In any case, the situation with MinGW-w64 is not the same as with
Cygwin: Cygwin has a version of xpm.h that is used with the X GUI and
another one that is used with the w32 GUI.  By contrast, MinGW-w64
doesn't support X, so it doesn't need to have 2 different headers by
the same name in the same include tree.

Did you try the alternative solution I suggested?  If not, please do:
I'm quite sure that it will work, and free you from the need to add
custom -I switches.

Message #71 received at 18302 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>, chriszheng99 <at> gmail.com,
 kbrown <at> cornell.edu, 18302 <at> debbugs.gnu.org
Subject: Re: bug#18302: MSYS2 build issues
Date: Tue, 28 Nov 2017 20:46:34 -0500

close 18302 
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 22 Aug 2014 16:18:11 +0200
>> From: Karol Ostrovsky <karol.ostrovsky <at> gmail.com>
>> Cc: Ken Brown <kbrown <at> cornell.edu>, Chris Zheng <chriszheng99 <at> gmail.com>, 18302 <at> debbugs.gnu.org
>> 
>> I will try to summarise the situation, and I am attaching my updated
>> solution proposal for this particular bug:
>> 
>> 1. MSYS2 uname must be handled properly, and that is fixed in the new
>> proposed patch.  I disagree with not renaming opsys from mingw32 to
>> mingw, since mingw32 string is used in other places in the same file
>> and it means something else there, which I find possibly confusing.
>> But this change is not in my new patch.
>> 
>> 2. -mtune is back to what it was with a minimal change required for
>> MSYS2+MinGW-w64 uname handling.
>> 
>> 3. Include path for xpm in MSYS2+MinGW-w64 is handled in the same way
>> as in Cygwin.  Perhaps, the same type of comment as was added for
>> Cygwin should be added for MSYS2+MinGW-w64.
>> 
>> 4. A loop is added in the recipe for emacs.exe to handle
>> bootstrap-emacs.exe busy problem.
>
> Thanks.  I installed items 1, 2, and 4, but not item 3.

As far as I can tell, there is nothing more to do here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.