[RFC] Correctly handling MinGW-w64

[RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

What follows are the required changes for detecting MinGW-w64 with the
sanctioned method, as discussed on

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18699#25

Please pay special attention to the configure.ac changes. This is the
first time (and hopefully the last) that I touch autoconf stuff.

Right now I can't test the change because the build fails with

./temacs: cannot execute binary file: Exec format error
Makefile:833: recipe for target 'bootstrap-emacs.exe' failed

This happens with the unpatched upstream Emacs sources.


Changes from master to working tree
8 files changed, 29 insertions(+), 14 deletions(-)
 admin/CPP-DEFINES |  3 ++-
 configure.ac      | 15 +++++++++++++++
 nt/addpm.c        |  5 ++---
 nt/inc/ms-w32.h   |  6 +++---
 nt/preprep.c      |  2 +-
 src/w32.c         |  4 ++--
 src/w32heap.c     |  4 ++--
 src/w32term.c     |  4 ++--

	Modified   admin/CPP-DEFINES
diff --git a/admin/CPP-DEFINES b/admin/CPP-DEFINES
index a98d1b9..18423c2 100644
--- a/admin/CPP-DEFINES
+++ b/admin/CPP-DEFINES
@@ -19,8 +19,9 @@ __MSDOS__	Ditto.
 __DJGPP_MINOR__ Minor version number of the DJGPP library; used only in msdos.c and dosfns.c.
 DOS_NT		Compiling for either the MS-DOS or native MS-Windows port.
 WINDOWSNT	Compiling the native MS-Windows (W32) port.
-__MINGW32__	Compiling the W32 port with the MinGW port of GCC.
+__MINGW32__	Compiling the W32 port with the MinGW or MinGW-w64 ports of GCC.
 _MSC_VER	Compiling the W32 port with the Microsoft C compiler.
+MINGW_W64	Compiling the W32 port with the MinGW-w64 port of GCC.
 DARWIN_OS	Compiling on Mac OS X or pure Darwin (and using s/darwin.h).
 SOLARIS2
 USG
	Modified   configure.ac
diff --git a/configure.ac b/configure.ac
index 5d71c2f..ed329f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1297,6 +1297,21 @@ case "$opsys" in
 esac
 
 
+dnl We need to distinguish MinGW32 toolset from its spin-off
+dnl MinGW-w64. (This has nothing to do with word size.)
+MINGW_W64=no
+if test $opsys = mingw32; then
+    AC_CHECK_DECL(__MINGW64_VERSION_MAJOR,
+                   MINGW_W64=yes,
+                   MINGW_W64=no,
+                   [#include <_mingw.h>])
+    if test "$MINGW_W64" = "yes"; then
+       AC_DEFINE([MINGW_W64], 1,
+          [Define to 1 if you are using the MinGW-w64 toolset, regardless of word size.])
+    fi
+fi
+
+
 C_SWITCH_MACHINE=
 case $canonical in
  alpha*)
	Modified   nt/addpm.c
diff --git a/nt/addpm.c b/nt/addpm.c
index 18057b5..7e58ef3 100644
--- a/nt/addpm.c
+++ b/nt/addpm.c
@@ -38,9 +38,8 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include <stdio.h>
 #include <malloc.h>
 
-/* MinGW64 defines _W64 and barfs if _WIN32_IE is defined to anything
-   below 0x500.  */
-#ifndef _W64
+/* MinGW64 barfs if _WIN32_IE is defined to anything below 0x500.  */
+#ifndef MINGW_W64
 #define _WIN32_IE 0x400
 #endif
 /* Request C Object macros for COM interfaces.  */
	Modified   nt/inc/ms-w32.h
diff --git a/nt/inc/ms-w32.h b/nt/inc/ms-w32.h
index edb143c..ff6a186 100644
--- a/nt/inc/ms-w32.h
+++ b/nt/inc/ms-w32.h
@@ -139,7 +139,7 @@ extern char *getenv ();
    versions we still support.  MinGW64 defines this to a higher value
    in its system headers, and is not really compatible with values
    lower than 0x0500, so leave it alone.  */
-#ifndef _W64
+#ifndef MINGW_W64
 # undef _WIN32_WINNT
 # define _WIN32_WINNT 0x0400
 #endif
@@ -167,7 +167,7 @@ extern char *getenv ();
 
 #ifdef emacs
 
-#ifdef _W64
+#ifdef MINGW_W64
 /* MinGW64 specific stuff.  */
 /* Make sure 'struct timespec' and 'struct timezone' are defined.  */
 #include <sys/types.h>
@@ -370,7 +370,7 @@ typedef int sigset_t;
 typedef int ssize_t;
 #endif
 
-#ifdef _W64	/* MinGW64 */
+#ifdef MINGW_W64
 #ifndef _POSIX
 typedef _sigset_t sigset_t;
 #endif
	Modified   nt/preprep.c
diff --git a/nt/preprep.c b/nt/preprep.c
index fda937d..39a9b70 100644
--- a/nt/preprep.c
+++ b/nt/preprep.c
@@ -25,7 +25,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
 #include <stdio.h>
 #include <fcntl.h>
 #include <time.h>
-#if defined(__GNUC__) && !defined(_W64)
+#if defined(__GNUC__) && !defined(MINGW_W64)
 #define _ANONYMOUS_UNION
 #define _ANONYMOUS_STRUCT
 #endif
	Modified   src/w32.c
diff --git a/src/w32.c b/src/w32.c
index f014cd7..8d8f536 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -72,7 +72,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include <pwd.h>
 #include <grp.h>
 
-/* MinGW64 (_W64) defines these in its _mingw.h.  */
+/* MinGW64 defines these in its _mingw.h.  */
 #ifndef _ANONYMOUS_UNION
 # define _ANONYMOUS_UNION
 #endif
@@ -151,7 +151,7 @@ typedef struct _PROCESS_MEMORY_COUNTERS_EX {
 #define SDDL_REVISION_1	1
 #endif	/* SDDL_REVISION_1 */
 
-#if defined(_MSC_VER) || defined(_W64)
+#if defined(_MSC_VER) || defined(MINGW_W64)
 /* MSVC and MinGW64 don't provide the definition of
    REPARSE_DATA_BUFFER and the associated macros, except on ntifs.h,
    which cannot be included because it triggers conflicts with other
	Modified   src/w32heap.c
diff --git a/src/w32heap.c b/src/w32heap.c
index c431b87..2a76641 100644
--- a/src/w32heap.c
+++ b/src/w32heap.c
@@ -214,7 +214,7 @@ dumped_data_commit (PVOID Base, PVOID *CommitAddress, PSIZE_T CommitSize)
 
 /* We want to turn on Low Fragmentation Heap for XP and older systems.
    MinGW32 lacks those definitions.  */
-#ifndef _W64
+#ifndef MINGW_W64
 typedef enum _HEAP_INFORMATION_CLASS {
   HeapCompatibilityInformation
 } HEAP_INFORMATION_CLASS;
@@ -244,7 +244,7 @@ init_heap (void)
       /* Create the private heap.  */
       heap = HeapCreate (0, 0, 0);
 
-#ifndef _W64
+#ifndef MINGW_W64
       /* Set the low-fragmentation heap for OS before Vista.  */
       HMODULE hm_kernel32dll = LoadLibrary ("kernel32.dll");
       HeapSetInformation_Proc s_pfn_Heap_Set_Information = (HeapSetInformation_Proc) GetProcAddress (hm_kernel32dll, "HeapSetInformation");
	Modified   src/w32term.c
diff --git a/src/w32term.c b/src/w32term.c
index c2a37d0..94b332b 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -101,10 +101,10 @@ extern Cursor w32_load_cursor (LPCTSTR name);
 struct w32_display_info one_w32_display_info;
 struct w32_display_info *x_display_list;
 
-#if _WIN32_WINNT < 0x0500 && !defined(_W64)
+#if _WIN32_WINNT < 0x0500 && !defined(MINGW_W64)
 /* Pre Windows 2000, this was not available, but define it here so
    that Emacs compiled on such a platform will run on newer versions.
-   MinGW64 (_W64) defines these unconditionally, so avoid redefining.  */
+   MinGW64 defines these unconditionally, so avoid redefining.  */
 
 typedef struct tagWCRANGE
 {

Re: [RFC] Correctly handling MinGW-w64

[Paul Eggert]

Óscar Fuentes wrote:
> +dnl We need to distinguish MinGW32 toolset from its spin-off
> +dnl MinGW-w64. (This has nothing to do with word size.)
> +MINGW_W64=no
> +if test $opsys = mingw32; then
> +    AC_CHECK_DECL(__MINGW64_VERSION_MAJOR,
> +                   MINGW_W64=yes,
> +                   MINGW_W64=no,
> +                   [#include <_mingw.h>])
> +    if test "$MINGW_W64" = "yes"; then
> +       AC_DEFINE([MINGW_W64], 1,
> +          [Define to 1 if you are using the MinGW-w64 toolset, regardless of word size.])
> +    fi
> +fi

Why does the above need to be in configure.ac?  Can the relevant code just 
inspect __MINGW64_VERSION_MAJOR instead of inspecting MINGW_W64?  Or, if we 
prefer to use our own symbol, can we just put something like this:

#ifdef __MINGW64_VERSION_MAJOR
# define MINGW_W64 1
#endif

into ms-w32.h or into some other header specific to Microsoft Windows?

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Right now I can't test the change because the build fails with
>
> ./temacs: cannot execute binary file: Exec format error
> Makefile:833: recipe for target 'bootstrap-emacs.exe' failed
>
> This happens with the unpatched upstream Emacs sources.

No problem while building a 64 bits Emacs, but fails while building the
32 bits Emacs. On a Windows 8.1 64 bits machine with MinGW-w64. Usually
I build my 32 bits Emacs on a Windows XP 32 bits. Too late to try there
now.

OTOH, I'm seeing lots of this on the build output:

Eager macro-expansion failure: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Óscar Fuentes wrote:
>> +dnl We need to distinguish MinGW32 toolset from its spin-off
>> +dnl MinGW-w64. (This has nothing to do with word size.)
>> +MINGW_W64=no
>> +if test $opsys = mingw32; then
>> +    AC_CHECK_DECL(__MINGW64_VERSION_MAJOR,
>> +                   MINGW_W64=yes,
>> +                   MINGW_W64=no,
>> +                   [#include <_mingw.h>])
>> +    if test "$MINGW_W64" = "yes"; then
>> +       AC_DEFINE([MINGW_W64], 1,
>> +          [Define to 1 if you are using the MinGW-w64 toolset, regardless of word size.])
>> +    fi
>> +fi
>
> Why does the above need to be in configure.ac?  Can the relevant code
> just inspect __MINGW64_VERSION_MAJOR instead of inspecting MINGW_W64?

The key here is that __MINGW64_VERSION_MAJOR is defined on a header
(_mingw.h) so we would need to do

#if __MINGW32__
#include <_mingw.h>
#if __MINGW64_VERSION_MAJOR
...

> Or, if we prefer to use our own symbol, can we just put something like
> this:
>
> #ifdef __MINGW64_VERSION_MAJOR
> # define MINGW_W64 1
> #endif
>
> into ms-w32.h or into some other header specific to Microsoft Windows?

We don't have a header that is included by all the .c files, right?
(apart from configure.h, of course.) The need to test for MINGW_W64 can
occur anywhere.

OTOH, I would be happy to use any practical solution that avoids
configure.ac.

Re: [RFC] Correctly handling MinGW-w64

[Paul Eggert]

Óscar Fuentes wrote:
>> into ms-w32.h or into some other header specific to Microsoft Windows?
> We don't have a header that is included by all the .c files, right?

Every .c file includes stdbool.h, string.h, and stdlib.h, via conf_post.h.  If 
none of those serve, you can include whatever file you like (stdio.h, say), in 
ms-w32.h or something like that.  There shouldn't be any need to bother 
'configure' about this.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Óscar Fuentes wrote:
>>> into ms-w32.h or into some other header specific to Microsoft Windows?
>> We don't have a header that is included by all the .c files, right?
>
> Every .c file includes stdbool.h, string.h, and stdlib.h, via
> conf_post.h.  If none of those serve, you can include whatever file
> you like (stdio.h, say), in ms-w32.h or something like that.

Doing that is a kludge. At some point on the future someone will change
how some of those files are #included (or remove them altogether). It is
fundamental that the MINGW_W64 define is guaranteed to be visible
everywhere. If we are using MinGW-w64 and some file checks MINGW_W64 but
has not it in scope, chances are that the build will carry on but things
will break in subtle ways at run time.

> There shouldn't be any need to bother 'configure' about this.

I thought that this type of tasks are the raison d'être of `configure'.

Re: [RFC] Correctly handling MinGW-w64

[Paul Eggert]

Óscar Fuentes wrote:
> I thought that this type of tasks are the raison d'être of `configure'.

No, the point of 'configure' is to do things that ordinary C and 'make' cannot. 
  Here, we have something that ordinary C can do, so 'configure' isn't needed.

> Doing that is a kludge.

Perhaps, but doing it in 'configure' is a worse kludge.  The stuff in 
'conf_post.h' is, by design, included everywhere, and it's the logical place to 
put global things that don't need 'configure''s help.

More generally, it would be better yet if we didn't need a global symbol 
indicating which particular minor flavor of a Microsoft Windows development 
environment is being used.  Symbols like that are needed in src/w32*.c but it'd 
be nicer if they didn't need to be used in generic code.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Óscar Fuentes wrote:
>> I thought that this type of tasks are the raison d'être of `configure'.
>
> No, the point of 'configure' is to do things that ordinary C and
> 'make' cannot. Here, we have something that ordinary C can do, so
> 'configure' isn't needed.

Ok.

>> Doing that is a kludge.
>
> Perhaps, but doing it in 'configure' is a worse kludge.  The stuff in
> 'conf_post.h' is, by design, included everywhere, and it's the logical
> place to put global things that don't need 'configure''s help.

After looking at it, seems that 'conf_post.h' can do the job. But
instead of placing the #define on some header that 'conf_post.h'
includes, I'll like to put it in 'conf_post.h' itself. There are similar
chunks of code there, so I guess that there is no problem.

> More generally, it would be better yet
[snip]

Indeed.

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 04:24:18 +0100
> 
> Right now I can't test the change because the build fails with
> 
> ./temacs: cannot execute binary file: Exec format error

Sounds like some Binutils problem.  Can you invoke the resulting
binary from the cmd.exe command line?

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 05:05:16 +0100
> 
> OTOH, I'm seeing lots of this on the build output:
> 
> Eager macro-expansion failure: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")

A known problem, not specific to Windows.

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 15:59:47 +0100
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> > Óscar Fuentes wrote:
> >>> into ms-w32.h or into some other header specific to Microsoft Windows?
> >> We don't have a header that is included by all the .c files, right?
> >
> > Every .c file includes stdbool.h, string.h, and stdlib.h, via
> > conf_post.h.  If none of those serve, you can include whatever file
> > you like (stdio.h, say), in ms-w32.h or something like that.
> 
> Doing that is a kludge. At some point on the future someone will change
> how some of those files are #included (or remove them altogether).

Whatever happens, ms-w32.h will always be included in conf_post.h.

> I thought that this type of tasks are the raison d'être of `configure'.

So did I.  I'm confused and perplexed to hear arguments to the
contrary.  Didn't we toss the src/s/*.h files for this very reason?

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> Date: Mon, 17 Nov 2014 07:18:45 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Óscar Fuentes wrote:
> > I thought that this type of tasks are the raison d'être of `configure'.
> 
> No, the point of 'configure' is to do things that ordinary C and 'make' cannot. 
>   Here, we have something that ordinary C can do, so 'configure' isn't needed.

But in practice, configure does also the other kind of thing.

> More generally, it would be better yet if we didn't need a global symbol 
> indicating which particular minor flavor of a Microsoft Windows development 
> environment is being used.  Symbols like that are needed in src/w32*.c but it'd 
> be nicer if they didn't need to be used in generic code.

Isn't that so in the patch?  Which parts of the patch, excluding
configure.ac, would you consider not Windows-specific?

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 16:42:37 +0100
> 
> After looking at it, seems that 'conf_post.h' can do the job.

Please do this in ms-w32.h (which is included by conf_post.h).

> But instead of placing the #define on some header that 'conf_post.h'
> includes, I'll like to put it in 'conf_post.h' itself. There are
> similar chunks of code there, so I guess that there is no problem.

The similar things there are for platforms that have n o other place
to put the.  Windows has ms-w32.h, so it's better to leave this stuff
there.

Thanks.

Re: [RFC] Correctly handling MinGW-w64

[Paul Eggert]

Eli Zaretskii wrote:
> Didn't we toss the src/s/*.h files for this very reason?

Of course.  But that was something different: those .h files contained 
information that could not be inferred from already-existing C code and 
therefore had to be configured.  They were handcrafted subroutines of 
'configure', so to speak, just as m4/*.m4 is now.  The case we are talking about 
is different, because this information can be inferred from already-existing C 
code.  Here, there's no need to involve 'configure' or any of its subroutines no 
matter what technology they use.

Given that we're now requiring GNU Make, I expect there's a lot of other stuff 
we could now move out of 'configure', if we had the time.  Which would be a good 
thing: 'configure' is reaaally slow and is a pain to maintain.  The smaller it 
is, the better.

Re: [RFC] Correctly handling MinGW-w64

[Paul Eggert]

Eli Zaretskii wrote:
> Isn't that so in the patch?  Which parts of the patch, excluding
> configure.ac, would you consider not Windows-specific?

Sorry, I didn't read the rest of the patch carefully.  If this symbol is needed 
only for code specific to that platform I agree that ms-w32.h is a better home 
for its definition.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Mon, 17 Nov 2014 04:24:18 +0100
>> 
>> Right now I can't test the change because the build fails with
>> 
>> ./temacs: cannot execute binary file: Exec format error
>
> Sounds like some Binutils problem.  Can you invoke the resulting
> binary from the cmd.exe command line?

No:

$ src/temacs.exe
bash: src/temacs.exe: cannot execute binary file: Exec format error

Doing the same from cmd.exe results on the OS showing a fancy banner
that says that this application can't run on my Pc, which I interpret as
the user friendly way of saying the same as bash says.

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> Date: Mon, 17 Nov 2014 08:02:22 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Given that we're now requiring GNU Make, I expect there's a lot of other stuff 
> we could now move out of 'configure', if we had the time.  Which would be a good 
> thing: 'configure' is reaaally slow and is a pain to maintain.  The smaller it 
> is, the better.

I'm fine with that, but let's try to be more consistent about that
than we are now, and let's also record that somewhere in admin/notes.
The fact that I was surprised is probably an indication that others
might be, too.

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> Date: Mon, 17 Nov 2014 08:03:56 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Isn't that so in the patch?  Which parts of the patch, excluding
> > configure.ac, would you consider not Windows-specific?
> 
> Sorry, I didn't read the rest of the patch carefully.  If this symbol is needed 
> only for code specific to that platform I agree that ms-w32.h is a better home 
> for its definition.

AFAICS, all the suggested changes are in w32-specific files, yes.

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 17:04:31 +0100
> 
> > Sounds like some Binutils problem.  Can you invoke the resulting
> > binary from the cmd.exe command line?
> 
> No:
> 
> $ src/temacs.exe
> bash: src/temacs.exe: cannot execute binary file: Exec format error
> 
> Doing the same from cmd.exe results on the OS showing a fancy banner
> that says that this application can't run on my Pc, which I interpret as
> the user friendly way of saying the same as bash says.

I suggest to take this up with MinGW64 developers.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Mon, 17 Nov 2014 17:04:31 +0100
>> 
>> > Sounds like some Binutils problem.  Can you invoke the resulting
>> > binary from the cmd.exe command line?
>> 
>> No:
>> 
>> $ src/temacs.exe
>> bash: src/temacs.exe: cannot execute binary file: Exec format error
>> 
>> Doing the same from cmd.exe results on the OS showing a fancy banner
>> that says that this application can't run on my Pc, which I interpret as
>> the user friendly way of saying the same as bash says.
>
> I suggest to take this up with MinGW64 developers.

Think that the MinGW64/MSYS2 developers know the issue. There is an
emacs-git build recipe in MSYS2 with no corresponding binary package,
because the build fails.

Right now the emacs master build finished correctly on Windows XP 32
bits with MSYS2 with the same binary packages as the Windows 8.1 64 bits
with MSYS2 64 bits, where the temacs.exe problem happens. It seems that
there is something on MSYS2 64 bits that affects how temacs.exe is
created. I'll mention this data point on the MSYS2 ml.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> After looking at it, seems that 'conf_post.h' can do the job.
>
> Please do this in ms-w32.h (which is included by conf_post.h).

Ok. Commit to master or emacs-24?

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 19:23:16 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> After looking at it, seems that 'conf_post.h' can do the job.
> >
> > Please do this in ms-w32.h (which is included by conf_post.h).
> 
> Ok. Commit to master or emacs-24?

emacs-24, please.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Ok. Commit to master or emacs-24?
>
> emacs-24, please.

The patch does not apply on emacs-24 (4 hunks fail). This can be
adapted, of course, but then there will be conflicts when merging
emacs-24 into master. I don't like the idea of forcing someone to fix
conflicts on areas he most probably don't know.

Since this is a correctness change that solves an hypothetical future
problem, I'm inclined to check it into master and leave emacs-24 as is.

Opinions?

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 20:04:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Ok. Commit to master or emacs-24?
> >
> > emacs-24, please.
> 
> The patch does not apply on emacs-24 (4 hunks fail). This can be
> adapted, of course, but then there will be conflicts when merging
> emacs-24 into master. I don't like the idea of forcing someone to fix
> conflicts on areas he most probably don't know.
> 
> Since this is a correctness change that solves an hypothetical future
> problem, I'm inclined to check it into master and leave emacs-24 as is.
> 
> Opinions?

How about applying to both (with a suitable "don't merge to trunk"
note on emacs-24)?

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > emacs-24, please.
>> 
>> The patch does not apply on emacs-24 (4 hunks fail). This can be
>> adapted, of course, but then there will be conflicts when merging
>> emacs-24 into master. I don't like the idea of forcing someone to fix
>> conflicts on areas he most probably don't know.
>> 
>> Since this is a correctness change that solves an hypothetical future
>> problem, I'm inclined to check it into master and leave emacs-24 as is.
>> 
>> Opinions?
>
> How about applying to both (with a suitable "don't merge to trunk"
> note on emacs-24)?

Not sure how to do that on an effective way.

Pushed the change to emacs-24. Let's see how it fares after the next
merge.

Re: [RFC] Correctly handling MinGW-w64

[Glenn Morris]

Óscar Fuentes wrote:

>> How about applying to both (with a suitable "don't merge to trunk"
>> note on emacs-24)?
>
> Not sure how to do that on an effective way.

Write "do not merge to trunk" in the commit log.

(And then wait for someone to implement a bzrmerge.el replacement so
that actually does something.)

> Pushed the change to emacs-24. Let's see how it fares after the next
> merge.

Ah yes, the "Somebody Else's Problem" method! :)

(The ideal solution would be for you to now merge emacs-24 to trunk and
resolve the conflicts yourself.)

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 17 Nov 2014 23:19:15 +0100
> 
> > How about applying to both (with a suitable "don't merge to trunk"
> > note on emacs-24)?
> 
> Not sure how to do that on an effective way.

I didn't mean anything fancy, just to apply to each branch separately,
resolving problems, if any.

> Pushed the change to emacs-24. Let's see how it fares after the next
> merge.

Thank you.

Re: [RFC] Correctly handling MinGW-w64

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Óscar Fuentes wrote:
>
>>> How about applying to both (with a suitable "don't merge to trunk"
>>> note on emacs-24)?
>>
>> Not sure how to do that on an effective way.
>
> Write "do not merge to trunk" in the commit log.
>
> (And then wait for someone to implement a bzrmerge.el replacement so
> that actually does something.)

Exactly. I know that gitmerge.el (or whatever) is not implemented, so
annotating the commit message has no effect.

>> Pushed the change to emacs-24. Let's see how it fares after the next
>> merge.
>
> Ah yes, the "Somebody Else's Problem" method! :)
>
> (The ideal solution would be for you to now merge emacs-24 to trunk and
> resolve the conflicts yourself.)

Just tried. Merging all those Changelogs is insane. After resolving all
the conflicts, I was not sure about the outcome, so scratched it.

If "Somebody Else" wishes to merge up to the prior commit of mine, I'll
merge it just afterwards. But after seeing the amount of conflicts on
the merge I tried, my change is the least of "Somebody Else"'s concerns.

Re: [RFC] Correctly handling MinGW-w64

[Stephen Leake]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Óscar Fuentes <ofv@wanadoo.es>
>>> Date: Mon, 17 Nov 2014 17:04:31 +0100
>>> 
>>> > Sounds like some Binutils problem.  Can you invoke the resulting
>>> > binary from the cmd.exe command line?
>>> 
>>> No:
>>> 
>>> $ src/temacs.exe
>>> bash: src/temacs.exe: cannot execute binary file: Exec format error
>>> 
>>> Doing the same from cmd.exe results on the OS showing a fancy banner
>>> that says that this application can't run on my Pc, which I interpret as
>>> the user friendly way of saying the same as bash says.
>>
>> I suggest to take this up with MinGW64 developers.
>
> Think that the MinGW64/MSYS2 developers know the issue. There is an
> emacs-git build recipe in MSYS2 with no corresponding binary package,
> because the build fails.
>
> Right now the emacs master build finished correctly on Windows XP 32
> bits with MSYS2 with the same binary packages as the Windows 8.1 64 bits
> with MSYS2 64 bits, where the temacs.exe problem happens. It seems that
> there is something on MSYS2 64 bits that affects how temacs.exe is
> created. I'll mention this data point on the MSYS2 ml.

I built emacs pretest 24.3.93, .94 successfully on Windows 7 64 bit
MSYS2 mingw32, but emacs-dynamic-module failed as above on the same
MSYS2 tools. So I think the problem is in the emacs code, although it
may be a change that encounters an MSYS bug.

I'll try again with current emacs master.

-- 
-- Stephe

Re: [RFC] Correctly handling MinGW-w64

[Stefan Monnier]

> Just tried. Merging all those Changelogs is insane.

No, that's the easy part: M-r does a "good enough" job (tho we like to
do it slightly differently).  The hard part is to deal with the code
conflicts: that's what the "don't merge to trunk" annotations are
really about.  Especially because some of those "don't merge to trunk"
might apply without textual conflict (yet should *not* be included: the
conflict is at a more conceptual/semantic level).


        Stefan

Re: [RFC] Correctly handling MinGW-w64

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Tue, 18 Nov 2014 02:24:10 -0600
> 
> I built emacs pretest 24.3.93, .94 successfully on Windows 7 64 bit
> MSYS2 mingw32, but emacs-dynamic-module failed as above on the same
> MSYS2 tools. So I think the problem is in the emacs code, although it
> may be a change that encounters an MSYS bug.

The only part of the Emacs code that could have any relation to this
is unexw32.c.  Does temacs.tmp (which is the output of the linker)
run?