Anyone building Emacs trunk with MinGW w64 (32 bits)

Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

gcc --version
gcc (rubenvb-4.7.2-release) 4.7.2

gcc -v
[...]
Target: i686-w64-mingw32
[...]

make bootstrap gives this errors:

gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/includ
e -DNO_LDAV=1 -DNO_ARCHIVES=1 -I../lib -I../nt/inc -I../src -DUSE_CRT_DLL=1 -o o
o-spd/i386/make-docfile.o make-docfile.c
In file included from ../src/conf_post.h:32:0,
                 from ../src/config.h:1726,
                 from make-docfile.c:37:
../nt/inc/ms-w32.h:269:8: error: redefinition of 'struct timespec'
In file included from ../nt/inc/ms-w32.h:133:0,
                 from ../src/conf_post.h:32,
                 from ../src/config.h:1726,
                 from make-docfile.c:37:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/sys/types.h:89:8: note: originally defined here
In file included from ../src/conf_post.h:32:0,
                 from ../src/config.h:1726,
                 from make-docfile.c:37:
../nt/inc/ms-w32.h:330:3: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:337:25: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:338:23: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:339:24: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:340:1: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:340:48: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:341:1: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:341:52: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:342:1: error: unknown type name 'sigset_t'
../nt/inc/ms-w32.h:371:0: warning: "_WIN32_WINNT" redefined [enabled by default]

In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/sys/types.h:13,
                 from ../nt/inc/ms-w32.h:133,
                 from ../src/conf_post.h:32,
                 from ../src/config.h:1726,
                 from make-docfile.c:37:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/_mingw.h:252:0: note: this is the location of the previous def
inition
mingw32-make[1]: *** [oo-spd/i386/make-docfile.o] Error 1
mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/lib-src'
mingw32-make: *** [bootstrap-gmake] Error 2


I tried going back in time on the Emacs sources up to points where I
know that the build worked with the old MinGW compiler that I used
before, and there are reports from people using MinGW 4.7.2 for building
Emacs, so there must be something different on the system headers of
MinGW W64.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 23 Mar 2013 15:32:52 +0100
> 
> gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/include -DNO_LDAV=1 -DNO_ARCHIVES=1 -I../lib -I../nt/inc -I../src -DUSE_CRT_DLL=1 -o oo-spd/i386/make-docfile.o make-docfile.c
> In file included from ../src/conf_post.h:32:0,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> ../nt/inc/ms-w32.h:269:8: error: redefinition of 'struct timespec'
> In file included from ../nt/inc/ms-w32.h:133:0,
>                  from ../src/conf_post.h:32,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/sys/types.h:89:8: note: originally defined here
> In file included from ../src/conf_post.h:32:0,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> ../nt/inc/ms-w32.h:330:3: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:337:25: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:338:23: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:339:24: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:340:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:340:48: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:341:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:341:52: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:342:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:371:0: warning: "_WIN32_WINNT" redefined [enabled by default]
> 
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/sys/types.h:13,
>                  from ../nt/inc/ms-w32.h:133,
>                  from ../src/conf_post.h:32,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/_mingw.h:252:0: note: this is the location of the previous definition
> mingw32-make[1]: *** [oo-spd/i386/make-docfile.o] Error 1
> mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/lib-src'
> mingw32-make: *** [bootstrap-gmake] Error 2
> 
> 
> I tried going back in time on the Emacs sources up to points where I
> know that the build worked with the old MinGW compiler that I used
> before, and there are reports from people using MinGW 4.7.2 for building
> Emacs, so there must be something different on the system headers of
> MinGW W64.

MinGW64 is a different project that MinGW32, developed by different
people.  The header files and libraries they provide are indeed
different from the ones provided by MinGW32.  If you really want to
use this toolchain, you will have to find out what causes these
problems, and suggest patches to avoid them (we will have to find a
preprocessor symbols to distinguish between MinGW32 and MinGW64 for
that to work).

Btw, I assume that you use MinGW64 as a cross-compiler to produce a
32-bit executable, not a 64-bit executable.  The latter needs even
more work to build and work.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> MinGW64 is a different project that MinGW32, developed by different
> people.  The header files and libraries they provide are indeed
> different from the ones provided by MinGW32.  If you really want to
> use this toolchain, you will have to find out what causes these
> problems, and suggest patches to avoid them (we will have to find a
> preprocessor symbols to distinguish between MinGW32 and MinGW64 for
> that to work).

Ok.

Indeed, the problem consists on differences in the header files. Seems
that MinGW64 is diverging from MinGW at a quick pace. Adapting Emacs to
those changes is a recipe for getting even more tangled preprocessor
code in Emacs. I'm not sure it is worth the trouble unless MinGW stalls.

> Btw, I assume that you use MinGW64 as a cross-compiler to produce a
> 32-bit executable, not a 64-bit executable.  The latter needs even
> more work to build and work.

The toolchain I'm using is composed of 32 bit executables that produces
32 bit executables, so no crosscompiling.

The `64' in MinGW64 is just an historical artifact, it doesn't mean that
the toolchain is restricted to 64 bit hosts.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 23 Mar 2013 16:49:37 +0100
> 
> Indeed, the problem consists on differences in the header files. Seems
> that MinGW64 is diverging from MinGW at a quick pace. Adapting Emacs to
> those changes is a recipe for getting even more tangled preprocessor
> code in Emacs. I'm not sure it is worth the trouble unless MinGW stalls.

You are probably right.  We will hit these problems one day anyway,
when we'd add support for 64-bit MinGW builds, which is only available
in MinGW64, at least for now.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Andy Moreton]

On Sat 23 Mar 2013, Eli Zaretskii wrote:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Sat, 23 Mar 2013 16:49:37 +0100
>> 
>> Indeed, the problem consists on differences in the header files. Seems
>> that MinGW64 is diverging from MinGW at a quick pace. Adapting Emacs to
>> those changes is a recipe for getting even more tangled preprocessor
>> code in Emacs. I'm not sure it is worth the trouble unless MinGW stalls.
>
> You are probably right.  We will hit these problems one day anyway,
> when we'd add support for 64-bit MinGW builds, which is only available
> in MinGW64, at least for now.

Given that Fedora and Cygwin both ship MinGW64 based cross compilers for
building native Windows binaries, that day would seem to be approaching.

    AndyM

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sat, 23 Mar 2013 19:47:38 +0000
> 
> > You are probably right.  We will hit these problems one day anyway,
> > when we'd add support for 64-bit MinGW builds, which is only available
> > in MinGW64, at least for now.
> 
> Given that Fedora and Cygwin both ship MinGW64 based cross compilers for
> building native Windows binaries, that day would seem to be approaching.

Building a native Windows Emacs on Posix platforms needs yet another
job to be done: support for a MinGW build in the Posix configury (the
configure script and Makefile.in files).  This is orthogonal to what I
mentioned above, and has to be done in addition.

Cross-compiling with MinGW on GNU/Linux (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Building a native Windows Emacs on Posix platforms needs yet another
> job to be done: support for a MinGW build in the Posix configury (the
> configure script and Makefile.in files).  This is orthogonal to what I
> mentioned above, and has to be done in addition.

And what about dumping and compiling .el files on a GNU/Linux host? The
later can be done with a native emacs, but how to create emacs.exe from
temacs.exe on a foreign platform? (using Wine, maybe?)

Re: Cross-compiling with MinGW on GNU/Linux (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 23 Mar 2013 21:18:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Building a native Windows Emacs on Posix platforms needs yet another
> > job to be done: support for a MinGW build in the Posix configury (the
> > configure script and Makefile.in files).  This is orthogonal to what I
> > mentioned above, and has to be done in addition.
> 
> And what about dumping and compiling .el files on a GNU/Linux host? The
> later can be done with a native emacs, but how to create emacs.exe from
> temacs.exe on a foreign platform? (using Wine, maybe?)

That's another part of that job, yes.

64-bit port (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[cg]

On 3/23/2013 11:25 PM, Eli Zaretskii wrote:
>
> Btw, I assume that you use MinGW64 as a cross-compiler to produce a
> 32-bit executable, not a 64-bit executable.  The latter needs even
> more work to build and work.
>

I am wondering what is happening to a 64-bit emacs for Windows, I recall
there was an effort on porting to windows [1], it seems Fabrice's patch has
not been applied to trunk yet, is it still going on?

[1] http://comments.gmane.org/gmane.emacs.devel/148666

Re: 64-bit port (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[Fabrice Popineau]

cg <chengang31 <at> gmail.com> writes:

> I am wondering what is happening to a 64-bit emacs for Windows, I recall
> there was an effort on porting to windows [1], it seems Fabrice's patch has
> not been applied to trunk yet, is it still going on?
> 
> [1] http://comments.gmane.org/gmane.emacs.devel/148666
> 
Hi,

Most of my patches for MSVC 64bits have been applied
over the time, thanks to Eli.
My own tree has a couple more diffs, but the current trunk
should compile with MSVC 64bits.
I hope to setup a web page explaining the process.
Obviously, you need the various libs too.

Regards,

Fabrice

Re: 64-bit port

[cg]

On 3/24/2013 10:00 PM, Fabrice Popineau wrote:
>
> Most of my patches for MSVC 64bits have been applied
> over the time, thanks to Eli.
> My own tree has a couple more diffs, but the current trunk
> should compile with MSVC 64bits.
> I hope to setup a web page explaining the process.
> Obviously, you need the various libs too.
>

When I compiled the current trunk, I still can't bootstrap it...

First I got an issue in get_current_dir_name(), which is just like this:
http://www.viva64.com/en/b/0033/

It is easy to fix by adding a declaration of getcwd() before use.

Then I got the error in batch compiling the lisp code:

Dumping from obj/AMD64/temacs.bin
           to obj/AMD64/temacs.exe
         "X:\emacs_files\trunk\bzr64\src/obj/AMD64/temacs.exe" -batch -l 
loadup bootstrap
...
Loading loadup.el (source)...
Using load-path (../lisp x:/emacs_files/trun
Loading emacs-lisp/byte-run (source)...
...
Loading international/mule-conf (source)...
Invalid function: "DEAD"

I am using VS2012, if that matters.

Re: 64-bit port (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sun, 24 Mar 2013 14:00:54 +0000 (UTC)
> 
> cg <chengang31 <at> gmail.com> writes:
> 
> > I am wondering what is happening to a 64-bit emacs for Windows, I recall
> > there was an effort on porting to windows [1], it seems Fabrice's patch has
> > not been applied to trunk yet, is it still going on?
> > 
> > [1] http://comments.gmane.org/gmane.emacs.devel/148666
> > 
> Hi,
> 
> Most of my patches for MSVC 64bits have been applied
> over the time, thanks to Eli.
> My own tree has a couple more diffs, but the current trunk
> should compile with MSVC 64bits.

Right.  But there's no 64-bit MinGW support yet.  nt/gmake.defs needs
some changes, and after that, whoever bites this bullet will need to
find solutions for incompatibilities between MinGW64 and MinGW32
headers, of the kind reported by Óscar.

Volunteers donating patches are welcome.

And thanks to Fabrice for his pioneer work which I believe took care
of most, if not all, problems with 64-bit Windows build per se (data
types etc.).

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 23 Mar 2013 15:32:52 +0100
> 
> gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/include -DNO_LDAV=1 -DNO_ARCHIVES=1 -I../lib -I../nt/inc -I../src -DUSE_CRT_DLL=1 -o o o-spd/i386/make-docfile.o make-docfile.c
> In file included from ../src/conf_post.h:32:0,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> ../nt/inc/ms-w32.h:269:8: error: redefinition of 'struct timespec'
> In file included from ../nt/inc/ms-w32.h:133:0,
>                  from ../src/conf_post.h:32,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/sys/types.h:89:8: note: originally defined here
> In file included from ../src/conf_post.h:32:0,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> ../nt/inc/ms-w32.h:330:3: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:337:25: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:338:23: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:339:24: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:340:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:340:48: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:341:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:341:52: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:342:1: error: unknown type name 'sigset_t'
> ../nt/inc/ms-w32.h:371:0: warning: "_WIN32_WINNT" redefined [enabled by default]
> 
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/sys/types.h:13,
>                  from ../nt/inc/ms-w32.h:133,
>                  from ../src/conf_post.h:32,
>                  from ../src/config.h:1726,
>                  from make-docfile.c:37:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/_mingw.h:252:0: note: this is the location of the previous definition
> mingw32-make[1]: *** [oo-spd/i386/make-docfile.o] Error 1
> mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/lib-src'
> mingw32-make: *** [bootstrap-gmake] Error 2

If you have a few moments to spare, please try again with the latest
trunk, I tried to fix at least these problems, so that Emacs will
compile with MinGW64.  But I don't have the headers installed by
MinGW64 GCC, and couldn't find them on the net, and I don't have time
to install MinGW64 and try the build myself.

Please report any problems you still have.

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> If you have a few moments to spare, please try again with the latest
> trunk, I tried to fix at least these problems, so that Emacs will
> compile with MinGW64.  But I don't have the headers installed by
> MinGW64 GCC, and couldn't find them on the net, and I don't have time
> to install MinGW64 and try the build myself.
>
> Please report any problems you still have.
>
> Thanks.

Starting from your patch, I'm slowly going through all the build
process.

Meanwhile, why is it necessary to bootstrap every time?

mingw32-make bootstrap

[... blah, blah, crash ]

mingw32-make

[...]

Essential Lisp files seem to be missing.  You should either
do `make bootstrap' or create `lisp/abbrev.elc' somehow.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> If you have a few moments to spare, please try again with the latest
> trunk, I tried to fix at least these problems, so that Emacs will
> compile with MinGW64.  But I don't have the headers installed by
> MinGW64 GCC, and couldn't find them on the net, and I don't have time
> to install MinGW64 and try the build myself.
>
> Please report any problems you still have.

I'm stuck on this:

w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'

In my install, that name is defined in

c:/mingw/i686-w64-mingw32/include/ddk/ntifs.h

Adding

#include <ntifs.h>

to w32.c doesn't work because the ddk directory is not in the automatic
search path of the compiler.

#include <ddk/ntifs.h>

doesn't work either because ntifs.h includes other files from the same
directory.

Searching the web shows that the "solution" is to add the ddk directory
to the search path with -I. But that creates a dependency on where
MinGWw64 was installed (not everybody installs con c:/mingw!)

Two places where the problem is discussed:

http://sourceforge.net/mailarchive/forum.php?thread_name=4E52E193.7090706%40users.sourceforge.net&forum_name=mingw-w64-public

http://sourceforge.net/tracker/?func=detail&aid=3407293&group_id=202880&atid=983355

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'

'REPARSE_DATA_BUFFER' is typedef'ed in w32.c with '#ifdef _MSC_VER'.
I think that it should be changed to '#if defined(_MSC_VER) || defined(__MINGW64__)'.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

rzl24ozi@gmail.com writes:

>> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
>
> 'REPARSE_DATA_BUFFER' is typedef'ed in w32.c with '#ifdef _MSC_VER'.
> I think that it should be changed to '#if defined(_MSC_VER) || defined(__MINGW64__)'.

Thanks! Unfortunately, it seems that there is no macro that
discriminates MinGWW64 from MinGW, so removed the #if for now.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

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

> rzl24ozi@gmail.com writes:
>
>>> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
>>
>> 'REPARSE_DATA_BUFFER' is typedef'ed in w32.c with '#ifdef _MSC_VER'.
>> I think that it should be changed to '#if defined(_MSC_VER) || defined(__MINGW64__)'.
>
> Thanks! Unfortunately, it seems that there is no macro that
> discriminates MinGWW64 from MinGW, so removed the #if for now.

With the changes below the project builds until

gcc -o oo-spd/i386/temacs.bin  -gdwarf-2 -g3   -Lc:/apps/GnuWin32/lib -Wl,-stack
,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x01000000 -Wl,-subsystem,conso
le -Wl,-entry,__start -Wl,-Map,oo-spd/i386/temacs.map oo-spd/i386/firstfile.o oo
-spd/i386/emacs.res oo-spd/i386/temacs0.a oo-spd/i386/temacs1.a oo-spd/i386/tema
cs2.a oo-spd/i386/lastfile.a ../lib/oo-spd/i386/libgnu.a -lwinmm -ladvapi32 -lgd
i32 -lcomdlg32 -luser32 -lmpr -lshell32 -lwinspool -lole32 -lcomctl32 -lusp10
oo-spd/i386/temacs1.a(fileio.o): In function `barf_or_query_if_file_exists':
D:\dev\emacs\emacs\src/fileio.c:1900: undefined reference to `_imp__lstat'
oo-spd/i386/temacs1.a(dired.o): In function `file_attributes':
D:\dev\emacs\emacs\src/dired.c:943: undefined reference to `_imp__fstatat'
oo-spd/i386/temacs1.a(dired.o): In function `file_name_completion_stat':
D:\dev\emacs\emacs\src/dired.c:818: undefined reference to `_imp__fstatat'
D:\dev\emacs\emacs\src/dired.c:820: undefined reference to `_imp__fstatat'
collect2.exe: error: ld returned 1 exit status
mingw32-make[3]: *** [oo-spd/i386/temacs.exe] Error 1
mingw32-make[3]: Leaving directory `D:/dev/emacs/emacs/src'



I have no time for investigating why the linker searches for lstat and
fstatat as if they were dllimports and ignores those defined in w32.c.

The changes are not intended to be committed into trunk, they are just
for the benefit of those who know what is going on.




	Modified   lib-src/ntlib.c
diff --git a/lib-src/ntlib.c b/lib-src/ntlib.c
index f431174..7d21e01 100644
--- a/lib-src/ntlib.c
+++ b/lib-src/ntlib.c
@@ -34,11 +34,13 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "ntlib.h"
 
+#ifndef _TIMESPEC_DEFINED
 struct timezone
 {
   int		tz_minuteswest;	/* minutes west of Greenwich */
   int		tz_dsttime;	/* type of dst correction */
 };
+#endif
 
 #define MAXPATHLEN _MAX_PATH
 
	Modified   nt/addpm.c
diff --git a/nt/addpm.c b/nt/addpm.c
index 6ed625d..c26fa93 100644
--- a/nt/addpm.c
+++ b/nt/addpm.c
@@ -34,7 +34,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    installed, then the DDE fallback for creating icons the Windows 3.1
    progman way will be used instead, but that is prone to lockups
    caused by other applications not servicing their message queues.  */
-#define _WIN32_IE 0x400
+/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
+/* 4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts */
+/* #define _WIN32_IE 0x400 */
 /* Request C Object macros for COM interfaces.  */
 #define COBJMACROS 1
 
	Modified   nt/config.nt
diff --git a/nt/config.nt b/nt/config.nt
index 1fe707c..26d7119 100644
--- a/nt/config.nt
+++ b/nt/config.nt
@@ -1146,6 +1146,13 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 /* Define to 1 if _setjmp and _longjmp work. */
 #define HAVE__SETJMP 1
 
+/* eval.c:963:3: error: too few arguments to function '_setjmp' */
+/* In file included from lisp.h:24:0, */
+/*                  from eval.c:24: */
+/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
+/* 4-mingw32/include/setjmp.h:164:63: note: declared here */
+#define USE_NO_MINGW_SETJMP_TWO_ARGS 1
+
 /* Define to 1 if you have the `__builtin_unwind_init' function. */
 #undef HAVE___BUILTIN_UNWIND_INIT
 
	Modified   nt/inc/ms-w32.h
diff --git a/nt/inc/ms-w32.h b/nt/inc/ms-w32.h
index d3faa6d..d2188a2 100644
--- a/nt/inc/ms-w32.h
+++ b/nt/inc/ms-w32.h
@@ -154,7 +154,7 @@ extern char *getenv ();
 
 #ifdef emacs
 
-#ifdef _MSC_VER
+#if 1
 #include <sys/timeb.h>
 #include <sys/stat.h>
 #include <signal.h>
	Modified   nt/inc/sys/time.h
diff --git a/nt/inc/sys/time.h b/nt/inc/sys/time.h
index e49f0ea..b6a016b 100644
--- a/nt/inc/sys/time.h
+++ b/nt/inc/sys/time.h
@@ -6,6 +6,10 @@
  * have the below stuff.
  */
 
+#include <sys/types.h>
+#include <time.h>
+
+#ifndef _TIMESPEC_DEFINED
 struct timeval
 {
   long		tv_sec;		/* seconds */
@@ -17,6 +21,7 @@ struct timezone
   int		tz_minuteswest;	/* minutes west of Greenwich */
   int		tz_dsttime;	/* type of dst correction */
 };
+#endif
 
 void gettimeofday (struct timeval *, struct timezone *);
 
@@ -24,13 +29,13 @@ void gettimeofday (struct timeval *, struct timezone *);
 #define ITIMER_PROF      1
 
 /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
-#ifndef _TIMESPEC_DEFINED
+// #ifndef _TIMESPEC_DEFINED
 struct itimerval
 {
   struct  timeval it_interval;	/* timer interval */
   struct  timeval it_value;	/* current value */
 };
-#endif
+// #endif
 
 int getitimer (int, struct itimerval *);
 int setitimer (int, struct itimerval *, struct itimerval *);
	Modified   src/w32.c
diff --git a/src/w32.c b/src/w32.c
index 647faf9..95aee3b 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -127,7 +127,7 @@ typedef struct _PROCESS_MEMORY_COUNTERS_EX {
 #define SDDL_REVISION_1	1
 #endif	/* SDDL_REVISION_1 */
 
-#ifdef _MSC_VER
+#if 1
 /* MSVC doesn'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 Windows API headers.  So
@@ -2386,28 +2386,31 @@ get_emacs_configuration_options (void)
 
 
 #include <sys/timeb.h>
+/* w32.c:2392:1: error: conflicting types for 'gettimeofday' */
+/* In file included from w32.c:32:0: */
+/* ../nt/inc/sys/time.h:25:6: note: previous declaration of 'gettimeofday' was here */
 
 /* Emulate gettimeofday (Ulrich Leodolter, 1/11/95).  */
-void
-gettimeofday (struct timeval *tv, struct timezone *tz)
-{
-  struct _timeb tb;
-  _ftime (&tb);
-
-  tv->tv_sec = tb.time;
-  tv->tv_usec = tb.millitm * 1000L;
-  /* Implementation note: _ftime sometimes doesn't update the dstflag
-     according to the new timezone when the system timezone is
-     changed.  We could fix that by using GetSystemTime and
-     GetTimeZoneInformation, but that doesn't seem necessary, since
-     Emacs always calls gettimeofday with the 2nd argument NULL (see
-     current_emacs_time).  */
-  if (tz)
-    {
-      tz->tz_minuteswest = tb.timezone;	/* minutes west of Greenwich  */
-      tz->tz_dsttime = tb.dstflag;	/* type of dst correction  */
-    }
-}
+/* void */
+/* gettimeofday (struct timeval *tv, struct timezone *tz) */
+/* { */
+/*   struct _timeb tb; */
+/*   _ftime (&tb); */
+
+/*   tv->tv_sec = tb.time; */
+/*   tv->tv_usec = tb.millitm * 1000L; */
+/*   /\* Implementation note: _ftime sometimes doesn't update the dstflag */
+/*      according to the new timezone when the system timezone is */
+/*      changed.  We could fix that by using GetSystemTime and */
+/*      GetTimeZoneInformation, but that doesn't seem necessary, since */
+/*      Emacs always calls gettimeofday with the 2nd argument NULL (see */
+/*      current_emacs_time).  *\/ */
+/*   if (tz) */
+/*     { */
+/*       tz->tz_minuteswest = tb.timezone;	/\* minutes west of Greenwich  *\/ */
+/*       tz->tz_dsttime = tb.dstflag;	/\* type of dst correction  *\/ */
+/*     } */
+/* } */
 
 /* Emulate fdutimens.  */
 
	Modified   src/w32term.c
diff --git a/src/w32term.c b/src/w32term.c
index e02b5a6..6c29470 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -109,7 +109,7 @@ struct w32_display_info *x_display_list;
 Lisp_Object w32_display_name_list;
 
 
-#if _WIN32_WINNT < 0x0500
+#if 0 // _WIN32_WINNT < 0x0500
 /* Pre Windows 2000, this was not available, but define it here so
    that Emacs compiled on such a platform will run on newer versions.  */
 

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 18:09:51 +0100
> 
> Meanwhile, why is it necessary to bootstrap every time?
> 
> mingw32-make bootstrap
> 
> [... blah, blah, crash ]

Crash or just an error?

> mingw32-make
> 
> [...]
> 
> Essential Lisp files seem to be missing.  You should either
> do `make bootstrap' or create `lisp/abbrev.elc' somehow.

The alternative is to bring the *.elc files from an already
bootstrapped tree.

Or, if you managed to get a working emacs.exe, compile the few Lisp
files by hand, until just "make" agrees to go on without requiring a
bootstrap.  Obviously, at least abbrev.elc will be needed, but maybe
others as well, I don't remember.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 20:11:12 +0100
> 
> rzl24ozi@gmail.com writes:
> 
> >> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
> >
> > 'REPARSE_DATA_BUFFER' is typedef'ed in w32.c with '#ifdef _MSC_VER'.
> > I think that it should be changed to '#if defined(_MSC_VER) || defined(__MINGW64__)'.
> 
> Thanks! Unfortunately, it seems that there is no macro that
> discriminates MinGWW64 from MinGW, so removed the #if for now.

Try this:

 #ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE

The MinGW32 headers define this in winnt.h, together with the
REPARSE_DATA_BUFFER data type.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 20:46:35 +0100
> 
> D:\dev\emacs\emacs\src/fileio.c:1900: undefined reference to `_imp__lstat'
> oo-spd/i386/temacs1.a(dired.o): In function `file_attributes':
> D:\dev\emacs\emacs\src/dired.c:943: undefined reference to `_imp__fstatat'
> oo-spd/i386/temacs1.a(dired.o): In function `file_name_completion_stat':
> D:\dev\emacs\emacs\src/dired.c:818: undefined reference to `_imp__fstatat'
> D:\dev\emacs\emacs\src/dired.c:820: undefined reference to `_imp__fstatat'
> collect2.exe: error: ld returned 1 exit status
> mingw32-make[3]: *** [oo-spd/i386/temacs.exe] Error 1
> mingw32-make[3]: Leaving directory `D:/dev/emacs/emacs/src'
> 
> 
> 
> I have no time for investigating why the linker searches for lstat and
> fstatat as if they were dllimports and ignores those defined in w32.c.

Try removing _CRTIMP from the prototypes in nt/inc/sys/stat.h.

> -#define _WIN32_IE 0x400
> +/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
> +/* 4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts */
> +/* #define _WIN32_IE 0x400 */

Please show the relevant parts of shlguid.h.

> --- a/nt/inc/ms-w32.h
> +++ b/nt/inc/ms-w32.h
> @@ -154,7 +154,7 @@ extern char *getenv ();
>  
>  #ifdef emacs
>  
> -#ifdef _MSC_VER
> +#if 1
>  #include <sys/timeb.h>
>  #include <sys/stat.h>
>  #include <signal.h>

What was the problem here?

> --- a/nt/inc/sys/time.h
> +++ b/nt/inc/sys/time.h
> @@ -6,6 +6,10 @@
>   * have the below stuff.
>   */
>  
> +#include <sys/types.h>
> +#include <time.h>
> +
> +#ifndef _TIMESPEC_DEFINED
>  struct timeval
>  {
>    long		tv_sec;		/* seconds */
> @@ -17,6 +21,7 @@ struct timezone
>    int		tz_minuteswest;	/* minutes west of Greenwich */
>    int		tz_dsttime;	/* type of dst correction */
>  };
> +#endif

And here?

>  /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
> -#ifndef _TIMESPEC_DEFINED
> +// #ifndef _TIMESPEC_DEFINED
>  struct itimerval
>  {
>    struct  timeval it_interval;	/* timer interval */
>    struct  timeval it_value;	/* current value */
>  };
> -#endif
> +// #endif

What's wrong with the #ifndef here?

> +/* w32.c:2392:1: error: conflicting types for 'gettimeofday' */
> +/* In file included from w32.c:32:0: */
> +/* ../nt/inc/sys/time.h:25:6: note: previous declaration of 'gettimeofday' was here */
>  
>  /* Emulate gettimeofday (Ulrich Leodolter, 1/11/95).  */
> -void
> -gettimeofday (struct timeval *tv, struct timezone *tz)

That's not the right solution.  There's no conflict between w32.c and
nt/inc/sys/time.h in how they declare/define gettimeofday.  The reason
must be something else, like the order of definition of the relevant
structures.  Presumably, by the time the prototype in time.h is seen,
one or both of the types of its arguments are not yet defined.  Please
look deeper.

> --- a/src/w32term.c
> +++ b/src/w32term.c
> @@ -109,7 +109,7 @@ struct w32_display_info *x_display_list;
>  Lisp_Object w32_display_name_list;
>  
>  
> -#if _WIN32_WINNT < 0x0500
> +#if 0 // _WIN32_WINNT < 0x0500
>  /* Pre Windows 2000, this was not available, but define it here so
>     that Emacs compiled on such a platform will run on newer versions.  */

What's the problem here?

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> [... blah, blah, crash ]
>
> Crash or just an error?

Error.

>> Essential Lisp files seem to be missing.  You should either
>> do `make bootstrap' or create `lisp/abbrev.elc' somehow.
>
> The alternative is to bring the *.elc files from an already
> bootstrapped tree.
>
> Or, if you managed to get a working emacs.exe, compile the few Lisp
> files by hand, until just "make" agrees to go on without requiring a
> bootstrap.  Obviously, at least abbrev.elc will be needed, but maybe
> others as well, I don't remember.

Thanks. I'll try it next time.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 20:11:12 +0100
> 
> Unfortunately, it seems that there is no macro that discriminates
> MinGWW64 from MinGW

Are you sure?  What does the command below produce?

  cpp -dM nul.c

By comparing what you get with what the MinGW version does, we might
be able to come up with a way to distinguish between them.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I have no time for investigating why the linker searches for lstat and
>> fstatat as if they were dllimports and ignores those defined in w32.c.
>
> Try removing _CRTIMP from the prototypes in nt/inc/sys/stat.h.

Yep, it works.

>> -#define _WIN32_IE 0x400
>> +/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
>> +/* 4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts */
>> +/* #define _WIN32_IE 0x400 */
>
> Please show the relevant parts of shlguid.h.

#ifndef _WIN32_IE
#define _WIN32_IE 0x0501
#else
/* FIXME: This really must be 0x0501 !!! */
#if (_WIN32_IE < 0x0500)
#error _WIN32_IE setting conflicts
#endif
#endif


>> --- a/nt/inc/ms-w32.h
>> +++ b/nt/inc/ms-w32.h
>> @@ -154,7 +154,7 @@ extern char *getenv ();
>>  
>>  #ifdef emacs
>>  
>> -#ifdef _MSC_VER
>> +#if 1
>>  #include <sys/timeb.h>
>>  #include <sys/stat.h>
>>  #include <signal.h>
>
> What was the problem here?

gcc -o oo-spd/i386/temacs.bin  -gdwarf-2 -g3   -Lc:/apps/GnuWin32/lib -Wl,-stack
,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x01000000 -Wl,-subsystem,conso
le -Wl,-entry,__start -Wl,-Map,oo-spd/i386/temacs.map oo-spd/i386/firstfile.o oo
-spd/i386/emacs.res oo-spd/i386/temacs0.a oo-spd/i386/temacs1.a oo-spd/i386/tema
cs2.a oo-spd/i386/lastfile.a ../lib/oo-spd/i386/libgnu.a -lwinmm -ladvapi32 -lgd
i32 -lcomdlg32 -luser32 -lmpr -lshell32 -lwinspool -lole32 -lcomctl32 -lusp10
c:/apps/msys/1.0/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-_fstat.o): In function `fst
at':
/home/ruben/mingw-w64/src/mingw-w64/mingw-w64-crt/stdio/_fstat.c:11: multiple de
finition of `fstat'
oo-spd/i386/temacs1.a(w32.o):D:\dev\emacs\emacs\src/w32.c:4320: first defined he
re
oo-spd/i386/temacs1.a(fileio.o): In function `Fset_file_modes':
D:\dev\emacs\emacs\src/fileio.c:3237: undefined reference to `_imp__sys_chmod'

>> --- a/nt/inc/sys/time.h
>> +++ b/nt/inc/sys/time.h
>> @@ -6,6 +6,10 @@
>>   * have the below stuff.
>>   */
>>  
>> +#include <sys/types.h>
>> +#include <time.h>
>> +
>> +#ifndef _TIMESPEC_DEFINED
>>  struct timeval
>>  {
>>    long		tv_sec;		/* seconds */
>> @@ -17,6 +21,7 @@ struct timezone
>>    int		tz_minuteswest;	/* minutes west of Greenwich */
>>    int		tz_dsttime;	/* type of dst correction */
>>  };
>> +#endif
>
> And here?

Avoid redefinition of timeval. The inclusion of sys/types.h is to ensure
that _TIMESPEC_DEFINED is defined. <time.h> is for bringing in MinGW64's
timeval. There are files that includes just nt/inc/sys/time.h for
timeval (hence #include <time.h> is required), others that include
<time.h> too for other purposes (hence removing the #if
_TIMESPEC_DEFINED is required for avoiding redefinition.)

>>  /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
>> -#ifndef _TIMESPEC_DEFINED
>> +// #ifndef _TIMESPEC_DEFINED
>>  struct itimerval
>>  {
>>    struct  timeval it_interval;	/* timer interval */
>>    struct  timeval it_value;	/* current value */
>>  };
>> -#endif
>> +// #endif
>
> What's wrong with the #ifndef here?

MinGW64 does not define itimerval.

>> +/* w32.c:2392:1: error: conflicting types for 'gettimeofday' */
>> +/* In file included from w32.c:32:0: */
>> +/* ../nt/inc/sys/time.h:25:6: note: previous declaration of 'gettimeofday' was here */
>>  
>>  /* Emulate gettimeofday (Ulrich Leodolter, 1/11/95).  */
>> -void
>> -gettimeofday (struct timeval *tv, struct timezone *tz)
>
> That's not the right solution.  There's no conflict between w32.c and
> nt/inc/sys/time.h in how they declare/define gettimeofday.  The reason
> must be something else, like the order of definition of the relevant
> structures.  Presumably, by the time the prototype in time.h is seen,
> one or both of the types of its arguments are not yet defined.  Please
> look deeper.

Okay.

>> --- a/src/w32term.c
>> +++ b/src/w32term.c
>> @@ -109,7 +109,7 @@ struct w32_display_info *x_display_list;
>>  Lisp_Object w32_display_name_list;
>>  
>>  
>> -#if _WIN32_WINNT < 0x0500
>> +#if 0 // _WIN32_WINNT < 0x0500
>>  /* Pre Windows 2000, this was not available, but define it here so
>>     that Emacs compiled on such a platform will run on newer versions.  */
>
> What's the problem here?

The enclosed definitions already are on MinGW64's headers, apparently
without the _WIN32_WINNT condition:

gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/includ
e -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -o oo-spd/i386/w32term.o w32ter
m.c
w32term.c:116:16: error: redefinition of 'struct tagWCRANGE'
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/windows.h:61:0,
                 from w32gui.h:21,
                 from w32term.h:21,
                 from w32term.c:25:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/wingdi.h:2536:18: note: originally defined here
w32term.c:120:3: error: conflicting types for 'WCRANGE'
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/windows.h:61:0,
                 from w32gui.h:21,
                 from w32term.h:21,
                 from w32term.c:25:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/wingdi.h:2539:5: note: previous declaration of 'WCRANGE' was h
ere
w32term.c:122:16: error: redefinition of 'struct tagGLYPHSET'
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/windows.h:61:0,
                 from w32gui.h:21,
                 from w32term.h:21,
                 from w32term.c:25:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/wingdi.h:2541:18: note: originally defined here
w32term.c:129:3: error: conflicting types for 'GLYPHSET'
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/windows.h:61:0,
                 from w32gui.h:21,
                 from w32term.h:21,
                 from w32term.c:25:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/wingdi.h:2547:5: note: previous declaration of 'GLYPHSET' was
here
mingw32-make[1]: *** [oo-spd/i386/w32term.o] Error 1

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> Date: Mon, 25 Mar 2013 23:24:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Mon, 25 Mar 2013 20:11:12 +0100
> > 
> > Unfortunately, it seems that there is no macro that discriminates
> > MinGWW64 from MinGW
> 
> Are you sure?  What does the command below produce?
> 
>   cpp -dM nul.c
> 
> By comparing what you get with what the MinGW version does, we might
> be able to come up with a way to distinguish between them.

If the above doesn't give any clues, I think __MINGW64_VERSION_MAJOR
might fit the bill.  But I'd expect to see __MINGW64__ in the output
of the above command.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Unfortunately, it seems that there is no macro that discriminates
>> MinGWW64 from MinGW
>
> Are you sure?  What does the command below produce?
>
>   cpp -dM nul.c

Already tried that. The only mention to MinGW is:

#define __MINGW32__ 1

> By comparing what you get with what the MinGW version does, we might
> be able to come up with a way to distinguish between them.

I don't have a MinGW install handy. Check yourself:

#define __DBL_MIN_EXP__ (-1021)
#define __pentiumpro__ 1
#define __UINT_LEAST16_MAX__ 65535
#define __ATOMIC_ACQUIRE 2
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __UINT_LEAST8_TYPE__ unsigned char
#define _WIN32 1
#define __INTMAX_C(c) c ## LL
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 255
#define __WINT_MAX__ 65535
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 4294967295U
#define __WCHAR_MAX__ 65535
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __FLT_EVAL_METHOD__ 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __UINT_FAST64_MAX__ 18446744073709551615ULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 2
#define __UINT_FAST8_MAX__ 255
#define _stdcall __attribute__((__stdcall__))
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __UINT_LEAST64_MAX__ 18446744073709551615ULL
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINT_LEAST8_MAX__ 255
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __UINTMAX_TYPE__ long long unsigned int
#define __DEC32_EPSILON__ 1E-6DF
#define __UINT32_MAX__ 4294967295U
#define __LDBL_MAX_EXP__ 16384
#define __WINT_MIN__ 0
#define __SCHAR_MAX__ 127
#define __WCHAR_MIN__ 0
#define __INT64_C(c) c ## LL
#define __DBL_DIG__ 15
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WIN32 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.19209289550781250000e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __DEC32_MAX__ 9.999999E96DF
#define __MINGW32__ 1
#define __INT32_MAX__ 2147483647
#define __SIZEOF_LONG__ 4
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 21
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define _cdecl __attribute__((__cdecl__))
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 12
#define __BIGGEST_ALIGNMENT__ 16
#define __i686 1
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define _thiscall __attribute__((__thiscall__))
#define __INT_FAST32_MAX__ 2147483647
#define __WINNT 1
#define __DBL_HAS_INFINITY__ 1
#define __WINNT__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __INT_FAST16_TYPE__ short int
#define _fastcall __attribute__((__fastcall__))
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __INT_LEAST32_MAX__ 2147483647
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __WIN32__ 1
#define __PTRDIFF_MAX__ 2147483647
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WINT_T__ 2
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __i686__ 1
#define __INT_FAST64_TYPE__ long long int
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __DECIMAL_BID_FORMAT__ 1
#define __GXX_TYPEINFO_EQUALITY_INLINE 0
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__ 
#define __UINT16_MAX__ 65535
#define __DBL_HAS_DENORM__ 1
#define __cdecl __attribute__((__cdecl__))
#define __UINT8_TYPE__ unsigned char
#define __NO_INLINE__ 1
#define __i386 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.7.2"
#define __UINT64_C(c) c ## ULL
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define _X86_ 1
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __INT32_C(c) c
#define __DEC64_EPSILON__ 1E-15DD
#define __ORDER_PDP_ENDIAN__ 3412
#define __DEC128_MIN_EXP__ (-6142)
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __INT16_MAX__ 32767
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __UINT64_MAX__ 18446744073709551615ULL
#define __INT8_TYPE__ signed char
#define __FLT_RADIX__ 2
#define __INT_LEAST16_TYPE__ short int
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __UINTMAX_C(c) c ## ULL
#define __SIG_ATOMIC_MAX__ 2147483647
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __SIZEOF_PTRDIFF_T__ 4
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __pentiumpro 1
#define __MSVCRT__ 1
#define __INT_FAST16_MAX__ 32767
#define __UINT_FAST32_MAX__ 4294967295U
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __UINT_FAST16_TYPE__ short unsigned int
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __CHAR16_TYPE__ short unsigned int
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __INT_LEAST16_MAX__ 32767
#define __DEC64_MANT_DIG__ 16
#define __INT64_MAX__ 9223372036854775807LL
#define __UINT_LEAST32_MAX__ 4294967295U
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __INT_LEAST64_TYPE__ long long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __DEC32_MAX_EXP__ 97
#define __INT_FAST8_MAX__ 127
#define __INTPTR_MAX__ 2147483647
#define __GXX_MERGED_TYPEINFO_NAMES 0
#define __stdcall __attribute__((__stdcall__))
#define __LDBL_MANT_DIG__ 64
#define __DBL_HAS_QUIET_NAN__ 1
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __INTPTR_TYPE__ int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ short unsigned int
#define __SIZEOF_FLOAT__ 4
#define __UINTPTR_MAX__ 4294967295U
#define __DEC64_MIN_EXP__ (-382)
#define __INT_FAST64_MAX__ 9223372036854775807LL
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __FLT_DIG__ 6
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT_MAX__ 2147483647
#define WIN32 1
#define __INT64_TYPE__ long long int
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __INT_LEAST64_MAX__ 9223372036854775807LL
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ short unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __LDBL_MIN_EXP__ (-16381)
#define __INT_LEAST8_MAX__ 127
#define __LDBL_MAX_10_EXP__ 4932
#define __ATOMIC_RELAXED 0
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
#define __thiscall __attribute__((__thiscall__))
#define __UINT8_C(c) c
#define __INT_LEAST32_TYPE__ int
#define __SIZEOF_WCHAR_T__ 2
#define __UINT64_TYPE__ long long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __fastcall __attribute__((__fastcall__))
#define __DBL_DECIMAL_DIG__ 17
#define __DEC_EVAL_METHOD__ 2
#define __ORDER_BIG_ENDIAN__ 4321
#define __UINT32_C(c) c ## U
#define __INTMAX_MAX__ 9223372036854775807LL
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define WINNT 1
#define __FLT_DENORM_MIN__ 1.40129846432481707092e-45F
#define __INT8_MAX__ 127
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.40282346638528859812e+38F
#define __INT32_TYPE__ int
#define __SIZEOF_DOUBLE__ 8
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define i386 1
#define _INTEGRAL_MAX_BITS 64
#define __DEC128_MAX_EXP__ 6145
#define __ATOMIC_CONSUME 1
#define __GNUC_MINOR__ 7
#define __UINTMAX_MAX__ 18446744073709551615ULL
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __INT16_C(c) c
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __ATOMIC_SEQ_CST 5
#define __UINT32_TYPE__ unsigned int
#define __UINTPTR_TYPE__ unsigned int
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-4931)
#define __SIZEOF_LONG_LONG__ 8
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __LDBL_DIG__ 18
#define __FLT_DECIMAL_DIG__ 9
#define __UINT_FAST16_MAX__ 65535
#define __GNUC_GNU_INLINE__ 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
#define __UINT_FAST8_TYPE__ unsigned char
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_RELEASE 3
#define __declspec(x) __attribute__((x))

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

With the following diff, the build creates emacs.exe. The issue about
gettimeofday is pending.

	Modified   lib-src/ntlib.c
diff --git a/lib-src/ntlib.c b/lib-src/ntlib.c
index f431174..7d21e01 100644
--- a/lib-src/ntlib.c
+++ b/lib-src/ntlib.c
@@ -34,11 +34,13 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "ntlib.h"
 
+#ifndef _TIMESPEC_DEFINED
 struct timezone
 {
   int		tz_minuteswest;	/* minutes west of Greenwich */
   int		tz_dsttime;	/* type of dst correction */
 };
+#endif
 
 #define MAXPATHLEN _MAX_PATH
 
	Modified   nt/addpm.c
diff --git a/nt/addpm.c b/nt/addpm.c
index 6ed625d..c26fa93 100644
--- a/nt/addpm.c
+++ b/nt/addpm.c
@@ -34,7 +34,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    installed, then the DDE fallback for creating icons the Windows 3.1
    progman way will be used instead, but that is prone to lockups
    caused by other applications not servicing their message queues.  */
-#define _WIN32_IE 0x400
+/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
+/* 4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts */
+/* #define _WIN32_IE 0x400 */
 /* Request C Object macros for COM interfaces.  */
 #define COBJMACROS 1
 
	Modified   nt/config.nt
diff --git a/nt/config.nt b/nt/config.nt
index 1fe707c..26d7119 100644
--- a/nt/config.nt
+++ b/nt/config.nt
@@ -1146,6 +1146,13 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 /* Define to 1 if _setjmp and _longjmp work. */
 #define HAVE__SETJMP 1
 
+/* eval.c:963:3: error: too few arguments to function '_setjmp' */
+/* In file included from lisp.h:24:0, */
+/*                  from eval.c:24: */
+/* c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6 */
+/* 4-mingw32/include/setjmp.h:164:63: note: declared here */
+#define USE_NO_MINGW_SETJMP_TWO_ARGS 1
+
 /* Define to 1 if you have the `__builtin_unwind_init' function. */
 #undef HAVE___BUILTIN_UNWIND_INIT
 
	Modified   nt/inc/ms-w32.h
diff --git a/nt/inc/ms-w32.h b/nt/inc/ms-w32.h
index d3faa6d..d2188a2 100644
--- a/nt/inc/ms-w32.h
+++ b/nt/inc/ms-w32.h
@@ -154,7 +154,7 @@ extern char *getenv ();
 
 #ifdef emacs
 
-#ifdef _MSC_VER
+#if 1
 #include <sys/timeb.h>
 #include <sys/stat.h>
 #include <signal.h>
	Modified   nt/inc/sys/stat.h
diff --git a/nt/inc/sys/stat.h b/nt/inc/sys/stat.h
index c356283..958349a 100644
--- a/nt/inc/sys/stat.h
+++ b/nt/inc/sys/stat.h
@@ -108,9 +108,9 @@ extern int w32_stat_get_owner_group;
 
 _CRTIMP int __cdecl __MINGW_NOTHROW	fstat (int, struct stat*);
 _CRTIMP int __cdecl __MINGW_NOTHROW	chmod (const char*, int);
-_CRTIMP int __cdecl __MINGW_NOTHROW	stat (const char*, struct stat*);
-_CRTIMP int __cdecl __MINGW_NOTHROW	lstat (const char*, struct stat*);
-_CRTIMP int __cdecl __MINGW_NOTHROW	fstatat (int, char const *,
+int __cdecl __MINGW_NOTHROW	stat (const char*, struct stat*);
+int __cdecl __MINGW_NOTHROW	lstat (const char*, struct stat*);
+int __cdecl __MINGW_NOTHROW	fstatat (int, char const *,
 						 struct stat *, int);
 
 #endif	/* INC_SYS_STAT_H_ */
	Modified   nt/inc/sys/time.h
diff --git a/nt/inc/sys/time.h b/nt/inc/sys/time.h
index e49f0ea..b6a016b 100644
--- a/nt/inc/sys/time.h
+++ b/nt/inc/sys/time.h
@@ -6,6 +6,10 @@
  * have the below stuff.
  */
 
+#include <sys/types.h>
+#include <time.h>
+
+#ifndef _TIMESPEC_DEFINED
 struct timeval
 {
   long		tv_sec;		/* seconds */
@@ -17,6 +21,7 @@ struct timezone
   int		tz_minuteswest;	/* minutes west of Greenwich */
   int		tz_dsttime;	/* type of dst correction */
 };
+#endif
 
 void gettimeofday (struct timeval *, struct timezone *);
 
@@ -24,13 +29,13 @@ void gettimeofday (struct timeval *, struct timezone *);
 #define ITIMER_PROF      1
 
 /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
-#ifndef _TIMESPEC_DEFINED
+// #ifndef _TIMESPEC_DEFINED
 struct itimerval
 {
   struct  timeval it_interval;	/* timer interval */
   struct  timeval it_value;	/* current value */
 };
-#endif
+// #endif
 
 int getitimer (int, struct itimerval *);
 int setitimer (int, struct itimerval *, struct itimerval *);
	Modified   src/w32.c
diff --git a/src/w32.c b/src/w32.c
index 647faf9..0a5c1e5 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -96,7 +96,7 @@ typedef struct _MEMORY_STATUS_EX {
 #ifndef _MSC_VER
 #include <w32api.h>
 #endif
-#if !defined (__MINGW32__) || __W32API_MAJOR_VERSION < 3 || (__W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION < 15)
+#if 0 // !defined (__MINGW32__) || __W32API_MAJOR_VERSION < 3 || (__W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION < 15)
 /* This either is not in psapi.h or guarded by higher value of
    _WIN32_WINNT than what we use.  w32api supplied with MinGW 3.15
    defines it in psapi.h  */
@@ -127,7 +127,7 @@ typedef struct _PROCESS_MEMORY_COUNTERS_EX {
 #define SDDL_REVISION_1	1
 #endif	/* SDDL_REVISION_1 */
 
-#ifdef _MSC_VER
+#if 1
 /* MSVC doesn'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 Windows API headers.  So
@@ -2386,28 +2386,31 @@ get_emacs_configuration_options (void)
 
 
 #include <sys/timeb.h>
+/* w32.c:2392:1: error: conflicting types for 'gettimeofday' */
+/* In file included from w32.c:32:0: */
+/* ../nt/inc/sys/time.h:25:6: note: previous declaration of 'gettimeofday' was here */
 
 /* Emulate gettimeofday (Ulrich Leodolter, 1/11/95).  */
-void
-gettimeofday (struct timeval *tv, struct timezone *tz)
-{
-  struct _timeb tb;
-  _ftime (&tb);
-
-  tv->tv_sec = tb.time;
-  tv->tv_usec = tb.millitm * 1000L;
-  /* Implementation note: _ftime sometimes doesn't update the dstflag
-     according to the new timezone when the system timezone is
-     changed.  We could fix that by using GetSystemTime and
-     GetTimeZoneInformation, but that doesn't seem necessary, since
-     Emacs always calls gettimeofday with the 2nd argument NULL (see
-     current_emacs_time).  */
-  if (tz)
-    {
-      tz->tz_minuteswest = tb.timezone;	/* minutes west of Greenwich  */
-      tz->tz_dsttime = tb.dstflag;	/* type of dst correction  */
-    }
-}
+/* void */
+/* gettimeofday (struct timeval *tv, struct timezone *tz) */
+/* { */
+/*   struct _timeb tb; */
+/*   _ftime (&tb); */
+
+/*   tv->tv_sec = tb.time; */
+/*   tv->tv_usec = tb.millitm * 1000L; */
+/*   /\* Implementation note: _ftime sometimes doesn't update the dstflag */
+/*      according to the new timezone when the system timezone is */
+/*      changed.  We could fix that by using GetSystemTime and */
+/*      GetTimeZoneInformation, but that doesn't seem necessary, since */
+/*      Emacs always calls gettimeofday with the 2nd argument NULL (see */
+/*      current_emacs_time).  *\/ */
+/*   if (tz) */
+/*     { */
+/*       tz->tz_minuteswest = tb.timezone;	/\* minutes west of Greenwich  *\/ */
+/*       tz->tz_dsttime = tb.dstflag;	/\* type of dst correction  *\/ */
+/*     } */
+/* } */
 
 /* Emulate fdutimens.  */
 
	Modified   src/w32term.c
diff --git a/src/w32term.c b/src/w32term.c
index e02b5a6..6c29470 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -109,7 +109,7 @@ struct w32_display_info *x_display_list;
 Lisp_Object w32_display_name_list;
 
 
-#if _WIN32_WINNT < 0x0500
+#if 0 // _WIN32_WINNT < 0x0500
 /* Pre Windows 2000, this was not available, but define it here so
    that Emacs compiled on such a platform will run on newer versions.  */
 

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 22:37:49 +0100
> 
> With the following diff, the build creates emacs.exe. The issue about
> gettimeofday is pending.

Thanks.

> --- a/nt/inc/sys/stat.h
> +++ b/nt/inc/sys/stat.h
> @@ -108,9 +108,9 @@ extern int w32_stat_get_owner_group;
>  
>  _CRTIMP int __cdecl __MINGW_NOTHROW	fstat (int, struct stat*);
>  _CRTIMP int __cdecl __MINGW_NOTHROW	chmod (const char*, int);
> -_CRTIMP int __cdecl __MINGW_NOTHROW	stat (const char*, struct stat*);
> -_CRTIMP int __cdecl __MINGW_NOTHROW	lstat (const char*, struct stat*);
> -_CRTIMP int __cdecl __MINGW_NOTHROW	fstatat (int, char const *,
> +int __cdecl __MINGW_NOTHROW	stat (const char*, struct stat*);
> +int __cdecl __MINGW_NOTHROW	lstat (const char*, struct stat*);
> +int __cdecl __MINGW_NOTHROW	fstatat (int, char const *,
>  						 struct stat *, int);

This doesn't look right: fstat is also provided by w32.c, so it should
have _CRTIMP removed from its prototype.  If that doesn't compile, we
will have to look for a more creative solution, because fstat from the
MS runtime is ABI-incompatible with fstat expected by Emacs (due to a
different definition of 'struct stat').

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Mar 2013 22:30:33 +0100
> 
> >>  /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
> >> -#ifndef _TIMESPEC_DEFINED
> >> +// #ifndef _TIMESPEC_DEFINED
> >>  struct itimerval
> >>  {
> >>    struct  timeval it_interval;	/* timer interval */
> >>    struct  timeval it_value;	/* current value */
> >>  };
> >> -#endif
> >> +// #endif
> >
> > What's wrong with the #ifndef here?
> 
> MinGW64 does not define itimerval.

Well, it will in a future version, because I see it on the MinGW64
development trunk.  So I guess we will need to us MinGW64 versions to
work around this safely, sigh...

I will look into the other issues tomorrow.  Thanks for the footwork.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

>> 'REPARSE_DATA_BUFFER' is typedef'ed in w32.c with '#ifdef _MSC_VER'.
>> I think that it should be changed to '#if defined(_MSC_VER) ||
>> defined(__MINGW64__)'.
>
> Thanks! Unfortunately, it seems that there is no macro that
> discriminates MinGWW64 from MinGW, so removed the #if for now.

I'm sorry, I made a mistake.
*i686*-w64-mingw32-gcc does not have a predefined macro __MINGW64__.

_W64 might be used to determine mingw-w64, but it is defined after #include <_mingw.h>.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

rzl24ozi@gmail.com writes:

>> Thanks! Unfortunately, it seems that there is no macro that
>> discriminates MinGWW64 from MinGW, so removed the #if for now.
>
> I'm sorry, I made a mistake.
> *i686*-w64-mingw32-gcc does not have a predefined macro __MINGW64__.
>
> _W64 might be used to determine mingw-w64, but it is defined after #include <_mingw.h>.

That could do, possibly with a gcc version check for detecting MinGW
distributions too old to contain _mingw.h, if necessary.

Thanks again.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Stefan Monnier]

>> Meanwhile, why is it necessary to bootstrap every time?
>> mingw32-make bootstrap
>> [... blah, blah, crash ]

> Crash or just an error?

>> mingw32-make
>> [...]
>> Essential Lisp files seem to be missing.  You should either
>> do `make bootstrap' or create `lisp/abbrev.elc' somehow.
> The alternative is to bring the *.elc files from an already
> bootstrapped tree.

Just for the record: this problem does not exist in the GNU/Linux build
procedure.  More specifically, in the Unix makefiles, "make bootstrap"
kind of like "make clean; make".  So presumably, by suitably changing
the Windows makefiles to mimick what the Unix makefiles do, we should be
able to get the same behavior.

Of course, making it possible to build the Windows version via
./configure would also solve it.


        Stefan

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Mon, 25 Mar 2013 22:24:53 -0400
> 
> Just for the record: this problem does not exist in the GNU/Linux build
> procedure.  More specifically, in the Unix makefiles, "make bootstrap"
> kind of like "make clean; make".  So presumably, by suitably changing
> the Windows makefiles to mimick what the Unix makefiles do, we should be
> able to get the same behavior.

Can't be done without a lot of non-trivial hacking, if at all
possible.  The Unix makefiles use Borne shell features to get this
done, and I don't want to require Windows users to have a native
Windows port of a Unixy shell installed (because there are no good
ones).

That said, feel free to donate patches to make this happen.

> Of course, making it possible to build the Windows version via
> ./configure would also solve it.

In the works, but I could use some help.  The main problem, which I'm
still unsure what is the best way of solving, is how to tell configure
not to test for certain features and instead accept that the test
should succeed (because those features are implemented in Emacs
sources).

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 02:40:55 +0100
> 
> rzl24ozi@gmail.com writes:
> 
> >> Thanks! Unfortunately, it seems that there is no macro that
> >> discriminates MinGWW64 from MinGW, so removed the #if for now.
> >
> > I'm sorry, I made a mistake.
> > *i686*-w64-mingw32-gcc does not have a predefined macro __MINGW64__.
> >
> > _W64 might be used to determine mingw-w64, but it is defined after #include <_mingw.h>.

Doesn't every MinGW64 header include _mingw.h?  I think they do, via
crtdefs.h.

> That could do, possibly with a gcc version check for detecting MinGW
> distributions too old to contain _mingw.h, if necessary.

Which distributions didn't?  I think they all do.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> Date: Tue, 26 Mar 2013 00:07:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Mon, 25 Mar 2013 22:30:33 +0100
> > 
> > >>  /* MinGW64 defines 'struct itimerval' and _TIMESPEC_DEFINED in sys/types.h.  */
> > >> -#ifndef _TIMESPEC_DEFINED
> > >> +// #ifndef _TIMESPEC_DEFINED
> > >>  struct itimerval
> > >>  {
> > >>    struct  timeval it_interval;	/* timer interval */
> > >>    struct  timeval it_value;	/* current value */
> > >>  };
> > >> -#endif
> > >> +// #endif
> > >
> > > What's wrong with the #ifndef here?
> > 
> > MinGW64 does not define itimerval.
> 
> Well, it will in a future version, because I see it on the MinGW64
> development trunk.  So I guess we will need to us MinGW64 versions to
> work around this safely, sigh...

That was a mistake on my part (as in "don't do anything important
after midnight"): there's no itimerval in MinGW64 headers.

> I will look into the other issues tomorrow.  Thanks for the footwork.

I installed a few more changes on the trunk, please see if there are
any issues left with the 32-bit MinGW64 build.

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

>> > _W64 might be used to determine mingw-w64, but it is defined after
>> > #include <_mingw.h>.
>
> Doesn't every MinGW64 header include _mingw.h?  I think they do, via
> crtdefs.h.

Oh, I wrote it because I was unsure where _mingw.h is included.
It seems that you are correct.

I'm trying to build by mingw-w64 at Cygwin.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Just for the record: this problem does not exist in the GNU/Linux build
>> procedure.  More specifically, in the Unix makefiles, "make bootstrap"
>> kind of like "make clean; make".  So presumably, by suitably changing
>> the Windows makefiles to mimick what the Unix makefiles do, we should be
>> able to get the same behavior.
>
> Can't be done without a lot of non-trivial hacking, if at all
> possible.  The Unix makefiles use Borne shell features to get this
> done, and I don't want to require Windows users to have a native
> Windows port of a Unixy shell installed (because there are no good
> ones).
>
> That said, feel free to donate patches to make this happen.
>
>> Of course, making it possible to build the Windows version via
>> ./configure would also solve it.
>
> In the works, but I could use some help.  The main problem, which I'm
> still unsure what is the best way of solving, is how to tell configure
> not to test for certain features and instead accept that the test
> should succeed (because those features are implemented in Emacs
> sources).

It seems to me that your two paragraphs contradict: on the first you say
that you don't want a Bourne shell on Windows, but in the second you say
that you are working on running the ./configure script on Windows (which
maybe does not require a Bourne shell, but some kind on Unix shell
anyway.)

What new requirements would add running ./configure on Windows, as per
your plan?

Instead on trying to force a square peg into a round hole, why not using
something native to Windows such as CMake, which adds a single, well
defined dependency to the build, and allows proper platform checks,
scriptability, etc.?

I know that this proposal was rejected twice before, but I'll bet that
making ./configure work on Windows would require less work than a
complete CMake build specification for Emacs.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I installed a few more changes on the trunk, please see if there are
> any issues left with the 32-bit MinGW64 build.

Fails in w32.c. This is the full output, not only the errors as in past
reports. I've seen the warnings about _WIN32_WINNT, _ANONYMOUS_UNION etc
before your changes.

gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/includ
e -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i3
86/w32.o w32.c
In file included from w32.c:32:0:
../nt/inc/sys/time.h:27:45: warning: 'struct timeval' declared inside parameter
list [enabled by default]
../nt/inc/sys/time.h:27:45: warning: its scope is only this definition or declar
ation, which is probably not what you want [enabled by default]
../nt/inc/sys/time.h:34:19: error: field 'it_interval' has incomplete type
../nt/inc/sys/time.h:35:19: error: field 'it_value' has incomplete type
In file included from w32.c:35:0:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/time.h:260:8: error: redefinition of 'struct timezone'
In file included from w32.c:32:0:
../nt/inc/sys/time.h:20:8: note: originally defined here
In file included from ./conf_post.h:32:0,
                 from ./config.h:1726,
                 from w32.c:39:
../nt/inc/ms-w32.h:134:0: warning: "_WIN32_WINNT" redefined [enabled by default]

In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/stddef.h:7,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/include/stddef.h:1,
                 from w32.c:22:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/_mingw.h:252:0: note: this is the location of the previous def
inition
w32.c:73:0: warning: "_ANONYMOUS_UNION" redefined [enabled by default]
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/stddef.h:7,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/include/stddef.h:1,
                 from w32.c:22:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/_mingw.h:575:0: note: this is the location of the previous def
inition
w32.c:74:0: warning: "_ANONYMOUS_STRUCT" redefined [enabled by default]
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/stddef.h:7,
                 from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/include/stddef.h:1,
                 from w32.c:22:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/_mingw.h:576:0: note: this is the location of the previous def
inition
w32.c:103:16: error: redefinition of 'struct _PROCESS_MEMORY_COUNTERS_EX'
In file included from w32.c:95:0:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/psapi.h:84:18: note: originally defined here
w32.c:115:3: error: conflicting types for 'PROCESS_MEMORY_COUNTERS_EX'
In file included from w32.c:95:0:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/psapi.h:96:5: note: previous declaration of 'PROCESS_MEMORY_CO
UNTERS_EX' was here
w32.c:115:31: error: conflicting types for 'PPROCESS_MEMORY_COUNTERS_EX'
In file included from w32.c:95:0:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/psapi.h:97:39: note: previous declaration of 'PPROCESS_MEMORY_
COUNTERS_EX' was here
w32.c:2392:1: error: conflicting types for 'gettimeofday'
In file included from w32.c:32:0:
../nt/inc/sys/time.h:27:6: note: previous declaration of 'gettimeofday' was here

w32.c:3216:1: warning: 'sys_chmod' redeclared without dllimport attribute: previ
ous dllimport ignored [-Wattributes]
w32.c: In function 'readlink':
w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
w32.c:4725:44: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this functi
on)
w32.c:4725:44: note: each undeclared identifier is reported only once for each f
unction it appears in
w32.c:4725:65: error: expected expression before ')' token
w32.c:4732:28: error: request for member 'ReparseTag' in something not a structu
re or union
w32.c:4743:18: error: request for member 'SymbolicLinkReparseBuffer' in somethin
g not a structure or union
w32.c:4745:18: error: request for member 'SymbolicLinkReparseBuffer' in somethin
g not a structure or union
w32.c:4746:20: error: request for member 'SymbolicLinkReparseBuffer' in somethin
g not a structure or union
mingw32-make[3]: *** [oo-spd/i386/w32.o] Error 1
mingw32-make[3]: Leaving directory `D:/dev/emacs/emacs/src'
mingw32-make[2]: *** [bootstrap-temacs-SH] Error 2
mingw32-make[2]: Leaving directory `D:/dev/emacs/emacs/src'
mingw32-make[1]: *** [bootstrap-temacs] Error 2
mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/src'
mingw32-make: *** [bootstrap-gmake] Error 2

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 12:10:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Just for the record: this problem does not exist in the GNU/Linux build
> >> procedure.  More specifically, in the Unix makefiles, "make bootstrap"
> >> kind of like "make clean; make".  So presumably, by suitably changing
> >> the Windows makefiles to mimick what the Unix makefiles do, we should be
> >> able to get the same behavior.
> >
> > Can't be done without a lot of non-trivial hacking, if at all
> > possible.  The Unix makefiles use Borne shell features to get this
> > done, and I don't want to require Windows users to have a native
> > Windows port of a Unixy shell installed (because there are no good
> > ones).
> >
> > That said, feel free to donate patches to make this happen.
> >
> >> Of course, making it possible to build the Windows version via
> >> ./configure would also solve it.
> >
> > In the works, but I could use some help.  The main problem, which I'm
> > still unsure what is the best way of solving, is how to tell configure
> > not to test for certain features and instead accept that the test
> > should succeed (because those features are implemented in Emacs
> > sources).
> 
> It seems to me that your two paragraphs contradict: on the first you say
> that you don't want a Bourne shell on Windows, but in the second you say
> that you are working on running the ./configure script on Windows (which
> maybe does not require a Bourne shell, but some kind on Unix shell
> anyway.)

There's no contradiction.  These are 2 different situations involved
here: the first one where Windows-specific makefiles are used with
native Windows tools, the second one where Unix makefiles are used
with tools that can produce and grok them.

> What new requirements would add running ./configure on Windows, as per
> your plan?

MSYS and the auxiliary MSYS tools will have to be installed on the
end-user system.

> Instead on trying to force a square peg into a round hole, why not using
> something native to Windows such as CMake, which adds a single, well
> defined dependency to the build, and allows proper platform checks,
> scriptability, etc.?

I've used CMake in a package much less complex than Emacs (Gawk, if
you want to know), and my conclusion was that it also requires some
non-trivial amount of tinkering, in order to work well with the MinGW
development environment.  And that tinkering needs good knowledge of
CMake, something not easily gleaned from the available docs.  So I see
no significant advantage going that way, unless mainline Emacs
development switches to CMake.

By contrast, using the Posix configure script and Posix Makefile.in
files will relieve us from at least one of the duties: the need to
track mainline development in a separate set of scripts that no one of
the head maintainers understands well, or wants to.  That is a huge
gain, which might just countermand the disadvantage of asking users to
install MSYS.

> I know that this proposal was rejected twice before, but I'll bet that
> making ./configure work on Windows would require less work than a
> complete CMake build specification for Emacs.

I guess you meant "less work" for CMake, not for ./configure.

However, my experience does not support your bet.  Running the current
configure script with MSYS tools is actually a no-brainer: I already
tried that, and it worked out of the box with no need to change
anything.

The only issue is what I mentioned above: that the configure script
probes the development environment, where many features are missing,
features that were implemented in the Emacs sources instead.

There's an easy way of forcing the configure script to pass tests
without trying (set the corresponding ac_* variables before running
the script).  But what I'd like to do is to maintain a text file with
a list of functions, header files, and other features that are
implemented in Emacs's own sources, and provide an automated way to
set those autoconf variables from that list.  This way, whenever a new
feature is added, all that will be need is to add a few lines to the
list.

Or maybe there's an easier/more elegant method of skipping autoconf
tests with known results.  I'm all ears.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> There's no contradiction.  These are 2 different situations involved
> here: the first one where Windows-specific makefiles are used with
> native Windows tools, the second one where Unix makefiles are used
> with tools that can produce and grok them.

Okay.

>> What new requirements would add running ./configure on Windows, as per
>> your plan?
>
> MSYS and the auxiliary MSYS tools will have to be installed on the
> end-user system.

Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit
the only allowed trespasser, for obvious reasons.)

I'm not saying that I'll stop building Emacs the day MSYS becomes a
requirement, but you'll admit that it is a heavy, potentially
problematic one.

> I've used CMake in a package much less complex than Emacs (Gawk, if
> you want to know), and my conclusion was that it also requires some
> non-trivial amount of tinkering, in order to work well with the MinGW
> development environment.  And that tinkering needs good knowledge of
> CMake, something not easily gleaned from the available docs.  So I see
> no significant advantage going that way, unless mainline Emacs
> development switches to CMake.

I'm not saying that it would be trivial. And some MinGW-specific
tinkering would be necessary, yes. But for the user it would be
hassle-free (well, CMake with the "MinGW Makefiles" generator doesn't
want a `sh.exe' on your PATH, but it explicitly tells you so when you
start the build.)

> By contrast, using the Posix configure script and Posix Makefile.in
> files will relieve us from at least one of the duties: the need to
> track mainline development in a separate set of scripts that no one of
> the head maintainers understands well, or wants to.  That is a huge
> gain, which might just countermand the disadvantage of asking users to
> install MSYS.

I'm not inclined to adding responsibilites to the users for the
(understandable) convenience of the developers, if other options exists.
Rather I'll prefer a system that is easy enough to maintain so the
hassle becomes less serious. And then, if the system is cross-platform
and there are developers who enjoy using it for their hacking, you'll
get some help for free.

>> I know that this proposal was rejected twice before, but I'll bet that
>> making ./configure work on Windows would require less work than a
>> complete CMake build specification for Emacs.
>
> I guess you meant "less work" for CMake, not for ./configure.

Yes, sorry.

> However, my experience does not support your bet.  Running the current
> configure script with MSYS tools is actually a no-brainer: I already
> tried that, and it worked out of the box with no need to change
> anything.
>
> The only issue is what I mentioned above: that the configure script
> probes the development environment, where many features are missing,
> features that were implemented in the Emacs sources instead.

One such thing is easily abstractable (sp?) on CMake: "run this platform
check unless this or that condition holds, for which the answer is
that."

The declarative/procedural nature of CMake makes so much things trivial
to implement compared against autotools/automake.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 12:48:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I installed a few more changes on the trunk, please see if there are
> > any issues left with the 32-bit MinGW64 build.
> 
> Fails in w32.c. This is the full output, not only the errors as in past
> reports. I've seen the warnings about _WIN32_WINNT, _ANONYMOUS_UNION etc
> before your changes.

I forgot that w32.c includes config.h only after including CRT
headers.  Will need some way of working around that...

Please also say "make -k" and post the results, so I could see all of
the problems that are left.

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 13:34:02 +0100
> 
> >> What new requirements would add running ./configure on Windows, as per
> >> your plan?
> >
> > MSYS and the auxiliary MSYS tools will have to be installed on the
> > end-user system.
> 
> Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit
> the only allowed trespasser, for obvious reasons.)

If you have MSYSGit installed, then resisting MSYS is kinda pointless,
don't you think?  Because you already have most of MSYS, and then
some.

> I'm not saying that I'll stop building Emacs the day MSYS becomes a
> requirement, but you'll admit that it is a heavy, potentially
> problematic one.

I agree that it's a disadvantage.  But most Free Software packages
already require to have MSYS installed to build a native MinGW port,
so it's not like Emacs will be the first offender here.

> > I've used CMake in a package much less complex than Emacs (Gawk, if
> > you want to know), and my conclusion was that it also requires some
> > non-trivial amount of tinkering, in order to work well with the MinGW
> > development environment.  And that tinkering needs good knowledge of
> > CMake, something not easily gleaned from the available docs.  So I see
> > no significant advantage going that way, unless mainline Emacs
> > development switches to CMake.
> 
> I'm not saying that it would be trivial. And some MinGW-specific
> tinkering would be necessary, yes. But for the user it would be
> hassle-free (well, CMake with the "MinGW Makefiles" generator doesn't
> want a `sh.exe' on your PATH, but it explicitly tells you so when you
> start the build.)

For the user it is hassle-free already.  In fact, it is even more
hassle-free than it could ever be with CMake: it doesn't require CMake
to be installed and configured.  (And if you think that's a
no-brainer, then ask me to tell you a horror story how I wasted an
hour trying to get CMake to work with my fully-functional MinGW
installation, due to a very subtle issue, not mentioned anywhere in
the docs and not found by Google.)

> > By contrast, using the Posix configure script and Posix Makefile.in
> > files will relieve us from at least one of the duties: the need to
> > track mainline development in a separate set of scripts that no one of
> > the head maintainers understands well, or wants to.  That is a huge
> > gain, which might just countermand the disadvantage of asking users to
> > install MSYS.
> 
> I'm not inclined to adding responsibilites to the users for the
> (understandable) convenience of the developers, if other options exists.

"Developer's convenience" my foot.  From my perspective, what's at
stake is the ability of keeping a viable Windows port alive!  How many
contributors to Emacs even understand the Windows build procedure well
enough to develop and maintain it?  Asking users who build their own
Emacs on Windows to install MSYS is a small price for making sure the
Windows port will be able to keep up with the Posix build procedure
for free.  For people who don't want to pay that price, there will
always be binary distributions.

> One such thing is easily abstractable (sp?) on CMake: "run this platform
> check unless this or that condition holds, for which the answer is
> that."

Right, but when you get to implement the condition, you get burned.
Sorry, I'm not convinced, and this time based on my own bitter,
though eventually successful enough, experience.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

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

> I'm trying to build by mingw-w64 at Cygwin.

I succeed to bootstrap mingw-w64 emacs (32bit and 64bit) by
the changes (for trunk r112139) attached to this mail on Cygwin
at Windows7 64bit.


gcc: mingw-w64 gcc 4.6.3 included in Strawberry Perl
     http://strawberryperl.com/

graphics (without svg) and xml libs: included in Strawberry Perl

svg libs: from http://ftp.gnome.org/pub/gnome/binaries/

gnutls libs (for mingw): from Linux rpm


I'm not sure that this changes is correct, but I hope that this
will help you.


[-- Attachment #2: w64.diff.gz --]
[-- Type: application/octet-stream, Size: 3516 bytes --]

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 12:48:37 +0100
> 
> gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/include -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/w32.o w32.c
> In file included from w32.c:32:0:
> ../nt/inc/sys/time.h:27:45: warning: 'struct timeval' declared inside parameter list [enabled by default]
> ../nt/inc/sys/time.h:27:45: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> ../nt/inc/sys/time.h:34:19: error: field 'it_interval' has incomplete type
> ../nt/inc/sys/time.h:35:19: error: field 'it_value' has incomplete type
> In file included from w32.c:35:0:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/time.h:260:8: error: redefinition of 'struct timezone'
> In file included from w32.c:32:0:
> ../nt/inc/sys/time.h:20:8: note: originally defined here

Still working on this part.

> In file included from ./conf_post.h:32:0,
>                  from ./config.h:1726,
>                  from w32.c:39:
> ../nt/inc/ms-w32.h:134:0: warning: "_WIN32_WINNT" redefined [enabled by default]
> 
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/stddef.h:7,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/include/stddef.h:1,
>                  from w32.c:22:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/_mingw.h:252:0: note: this is the location of the previous definition
> w32.c:73:0: warning: "_ANONYMOUS_UNION" redefined [enabled by default]
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/stddef.h:7,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/include/stddef.h:1,
>                  from w32.c:22:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/_mingw.h:575:0: note: this is the location of the previous definition
> w32.c:74:0: warning: "_ANONYMOUS_STRUCT" redefined [enabled by default]
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/crtdefs.h:10:0,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/stddef.h:7,
>                  from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/include/stddef.h:1,
>                  from w32.c:22:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/_mingw.h:576:0: note: this is the location of the previous definition
> w32.c:103:16: error: redefinition of 'struct _PROCESS_MEMORY_COUNTERS_EX'
> In file included from w32.c:95:0:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/psapi.h:84:18: note: originally defined here
> w32.c:115:3: error: conflicting types for 'PROCESS_MEMORY_COUNTERS_EX'
> In file included from w32.c:95:0:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/psapi.h:96:5: note: previous declaration of 'PROCESS_MEMORY_COUNTERS_EX' was here
> w32.c:115:31: error: conflicting types for 'PPROCESS_MEMORY_COUNTERS_EX'
> In file included from w32.c:95:0:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/psapi.h:97:39: note: previous declaration of 'PPROCESS_MEMORY_COUNTERS_EX' was here

These should hopefully be fixed with the latest trunk, please check.

> w32.c:2392:1: error: conflicting types for 'gettimeofday'
> In file included from w32.c:32:0:
> ../nt/inc/sys/time.h:27:6: note: previous declaration of 'gettimeofday' was here

This is due to the same problem as the first error above, so not fixed
yet.

> w32.c:3216:1: warning: 'sys_chmod' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]

This should now be fixed, please check.

> w32.c: In function 'readlink':
> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
> w32.c:4725:44: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this function)

This got me puzzled: the definition of REPARSE_DATA_BUFFER is now
guarded by this:

 #ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE

Are you saying that MAXIMUM_REPARSE_DATA_BUFFER_SIZE is defined in the
MinGW64 build, but REPARSE_DATA_BUFFER is not?  Which MinGW64 headers
define MAXIMUM_REPARSE_DATA_BUFFER_SIZE and REPARSE_DATA_BUFFER?

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> Date: Tue, 26 Mar 2013 15:54:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Tue, 26 Mar 2013 12:48:37 +0100
> > 
> > gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/include -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/w32.o w32.c
> > In file included from w32.c:32:0:
> > ../nt/inc/sys/time.h:27:45: warning: 'struct timeval' declared inside parameter list [enabled by default]
> > ../nt/inc/sys/time.h:27:45: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > ../nt/inc/sys/time.h:34:19: error: field 'it_interval' has incomplete type
> > ../nt/inc/sys/time.h:35:19: error: field 'it_value' has incomplete type
> > In file included from w32.c:35:0:
> > c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/time.h:260:8: error: redefinition of 'struct timezone'
> > In file included from w32.c:32:0:
> > ../nt/inc/sys/time.h:20:8: note: originally defined here
> 
> Still working on this part.

I hope this is fixed on the trunk now, please test.

> > w32.c:2392:1: error: conflicting types for 'gettimeofday'
> > In file included from w32.c:32:0:
> > ../nt/inc/sys/time.h:27:6: note: previous declaration of 'gettimeofday' was here
> 
> This is due to the same problem as the first error above, so not fixed
> yet.

And this as well.

> > w32.c: In function 'readlink':
> > w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
> > w32.c:4725:44: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this function)
> 
> This got me puzzled: the definition of REPARSE_DATA_BUFFER is now
> guarded by this:
> 
>  #ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE
> 
> Are you saying that MAXIMUM_REPARSE_DATA_BUFFER_SIZE is defined in the
> MinGW64 build, but REPARSE_DATA_BUFFER is not?  Which MinGW64 headers
> define MAXIMUM_REPARSE_DATA_BUFFER_SIZE and REPARSE_DATA_BUFFER?

This part is still pending.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Tue, 26 Mar 2013 22:52:15 +0900
> 
> > I'm trying to build by mingw-w64 at Cygwin.
> 
> I succeed to bootstrap mingw-w64 emacs (32bit and 64bit) by
> the changes (for trunk r112139) attached to this mail on Cygwin
> at Windows7 64bit.

Thanks.  But what does it mean "on Cygwin" in this context?  If you
are building with the MinGW64 tools, what Cygwin has got to do with
this?

> I'm not sure that this changes is correct, but I hope that this
> will help you.

They are helpful, but I have a few questions:

  --- ./nt/addpm.c.orig	2013-03-26 17:33:23.000000000 +0900
  +++ ./nt/addpm.c	2013-03-26 21:46:23.405698700 +0900
  @@ -34,15 +34,17 @@
      installed, then the DDE fallback for creating icons the Windows 3.1
      progman way will be used instead, but that is prone to lockups
      caused by other applications not servicing their message queues.  */
  -/* MinGW64 defines _W64 and barfs if _WIN32_IE is defined to anything
  -   below 0x500.  */
  -#ifndef _W64
   #define _WIN32_IE 0x400
  -#endif
   /* Request C Object macros for COM interfaces.  */
   #define COBJMACROS 1

   #include <windows.h>
  +/* MinGW64 defines _W64 and barfs if _WIN32_IE is defined to anything
  +   below 0x500.  */
  +#ifdef _W64
  +#undef _WIN32_IE
  +#define _WIN32_IE 0x500
  +#endif

What was wrong with the original code, and why did you need to move
the definition of _WIN32_IE further down?  What error messages did you
see with the original code?

  --- ./nt/configure.bat.orig	2013-03-26 22:06:16.528698700 +0900
  +++ ./nt/configure.bat	2013-03-26 22:06:16.492698700 +0900
  @@ -479,10 +479,10 @@
   echo Using 'gcc'
   rm -f junk.c junk.o
   Rem It is not clear what GCC version began supporting -mtune
  -Rem and pentium4 on x86, so check this explicitly.
  +Rem and i686 on x86, so check this explicitly.
   echo main(){} >junk.c
  -echo gcc -c -O2 -mtune=pentium4 junk.c >>config.log
  -gcc -c -O2 -mtune=pentium4 junk.c >>config.log 2>&1
  +echo gcc -c -O2 -mtune=i686 junk.c >>config.log
  +gcc -c -O2 -mtune=i686 junk.c >>config.log 2>&1

What was wrong with the original gcc commands?

  #ifdef _W64
  /* MinGW64 specific stuff.  */
 -#define USE_NO_MINGW_SETJMP_TWO_ARGS 1
  /* Make sure 'struct timespec' and 'struct timezone' are defined.  */
  #include <sys/types.h>
 +#include <sys/stat.h>
  #include <time.h>
 +#ifdef WIN64
 +#define _start __start
 +#endif
  #endif

  #ifdef _MSC_VER

Please explain why these changes to ms-w32.h were needed.

  --- ./nt/inc/sys/time.h.orig	2013-03-26 17:33:23.000000000 +0900
  +++ ./nt/inc/sys/time.h	2013-03-26 21:46:23.425698700 +0900
  @@ -8,7 +8,8 @@

   /* The guards are for MinGW64, which defines these structs on its
      system headers which are included by ms-w32.h.  */
  -#ifndef _W64
  +#if !defined(_TIMEVAL_DEFINED) || !defined(_W64)
  +#define _TIMEVAL_DEFINED
   struct timeval
   {
     long		tv_sec;		/* seconds */

This breaks the MinGW32 build, so please see if the current trunk has
a better solution for this problem.

    --- ./src/image.c.orig	2013-03-24 18:16:45.000000000 +0900
    +++ ./src/image.c	2013-03-26 21:46:23.437698700 +0900
    @@ -5545,6 +5545,9 @@
       png_byte **rows;
     };

    +#ifdef _W64
    +#define _setjmp setjmp
    +#endif

Why is this needed?

  --- ./src/lisp.h.orig	2013-03-25 12:31:37.000000000 +0900
  +++ ./src/lisp.h	2013-03-26 21:46:23.442698700 +0900
  @@ -2164,7 +2164,11 @@

   #ifdef HAVE__SETJMP
   typedef jmp_buf sys_jmp_buf;
  +#ifdef _W64
  +# define sys_setjmp(j) setjmp (j)
  +#else
   # define sys_setjmp(j) _setjmp (j)
  +#endif
   # define sys_longjmp(j, v) _longjmp (j, v)

And this?

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

  --- ./nt/emacsclient.rc.orig	2013-01-03 12:31:15.000000000 +0900
  +++ ./nt/emacsclient.rc	2013-03-26 21:46:23.417698700 +0900
  @@ -1,4 +1,9 @@
   Emacs ICON   icons\emacs.ico
  +#ifdef WIN64
  +1 24 "emacs-x64.manifest"
  +#else
  +1 24 "emacs-x86.manifest"
  +#endif

   #ifndef VS_VERSION_INFO

Is there any reason you needed a manifest for emacsclient?  Did you
see elevation prompts or something?

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

> Thanks.  But what does it mean "on Cygwin" in this context?  If you
> are building with the MinGW64 tools, what Cygwin has got to do with
> this?

It mean that I use MinGW64 tools on Cygwin shell.
I think Cygwin is not important.

>  --- ./nt/addpm.c.orig	2013-03-26 17:33:23.000000000 +0900
>  +++ ./nt/addpm.c	2013-03-26 21:46:23.405698700 +0900
>  @@ -34,15 +34,17 @@
    :
> What was wrong with the original code, and why did you need to move
> the definition of _WIN32_IE further down?  What error messages did you
> see with the original code?

Because _W64 is defined after include MinGW64 header.

>   --- ./nt/configure.bat.orig	2013-03-26 22:06:16.528698700 +0900
>   +++ ./nt/configure.bat	2013-03-26 22:06:16.492698700 +0900
>   @@ -479,10 +479,10 @@
    :
> What was wrong with the original gcc commands?

"-mtune=pentium4" cause an error in 64bit gcc, like
"hello.c:1:0: error: CPU you selected does not support x86-64 instruction set"

If "-mtune=pentium4" is failed configure.bat use "-mcpu=i686" instead,
but it cause gcc warnig like
"gcc.exe: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead"

>   #ifdef _W64
>   /* MinGW64 specific stuff.  */
>  -#define USE_NO_MINGW_SETJMP_TWO_ARGS 1
>   /* Make sure 'struct timespec' and 'struct timezone' are defined.  */
>   #include <sys/types.h>
>  +#include <sys/stat.h>
>   #include <time.h>
>  +#ifdef WIN64
>  +#define _start __start
>  +#endif
>   #endif
>
>   #ifdef _MSC_VER
>
> Please explain why these changes to ms-w32.h were needed.

If USE_NO_MINGW_SETJMP_TWO_ARGS is defined, it seems that emacs crash
when byte-compile. I do not know what happened in this case exactly,
sorry.

In ms-w32.h, some functions are defined to sys_...,
such as chmod -> sys_chmod.
if it is defined before "#include <sys/stat.h>",
functions in sys/stat.h are changed.
It cause warning like "warning: 'sys_chmod' redeclared without
dllimport...", I think. so I include it here.

__start is entry point that specified by linker option in makefile,
but 64bit gcc does not add '_' to symbol, so change _start to
__start.

>   --- ./nt/inc/sys/time.h.orig	2013-03-26 17:33:23.000000000 +0900
>   +++ ./nt/inc/sys/time.h	2013-03-26 21:46:23.425698700 +0900
    :
> This breaks the MinGW32 build, so please see if the current trunk has
> a better solution for this problem.

I understand.

>     --- ./src/image.c.orig	2013-03-24 18:16:45.000000000 +0900
>     +++ ./src/image.c	2013-03-26 21:46:23.437698700 +0900
>     @@ -5545,6 +5545,9 @@
>        png_byte **rows;
>      };
>
>     +#ifdef _W64
>     +#define _setjmp setjmp
>     +#endif
>
> Why is this needed?

In image.c, _setjmp() is used with 1 arg. It seems that some compile error.
This is also related to the following.

>   --- ./src/lisp.h.orig	2013-03-25 12:31:37.000000000 +0900
>   +++ ./src/lisp.h	2013-03-26 21:46:23.442698700 +0900
>   @@ -2164,7 +2164,11 @@
>
>    #ifdef HAVE__SETJMP
>    typedef jmp_buf sys_jmp_buf;
>   +#ifdef _W64
>   +# define sys_setjmp(j) setjmp (j)
>   +#else
>    # define sys_setjmp(j) _setjmp (j)
>   +#endif
>    # define sys_longjmp(j, v) _longjmp (j, v)
>
> And this?

If USE_NO_MINGW_SETJMP_TWO_ARGS is not defined,
it seems that _setjmp() need 2 args (see mingw-w64's setjmp.h).
so I change this.

Sorry for my poor english. I'm not english native.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Mar 2013 00:48:58 +0900
> 
> Sorry for my poor english. I'm not english native.

There's nothing wrong with your English.  Thanks for the info, it is
very useful.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit
>> the only allowed trespasser, for obvious reasons.)
>
> If you have MSYSGit installed, then resisting MSYS is kinda pointless,
> don't you think?  Because you already have most of MSYS, and then
> some.

AFAIK, MSYSGit lacks key components for running configure scripts.

> "Developer's convenience" my foot.  From my perspective, what's at
> stake is the ability of keeping a viable Windows port alive!

Yes, that's my concern too.

> How many
> contributors to Emacs even understand the Windows build procedure well
> enough to develop and maintain it?  Asking users who build their own
> Emacs on Windows to install MSYS is a small price for making sure the
> Windows port will be able to keep up with the Posix build procedure
> for free.  For people who don't want to pay that price, there will
> always be binary distributions.

The POSIX build will require Windows-specific tweaks from time to time,
which require knowledge about the POSIX build *and* about Windows.
That's not much better than now.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 17:17:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit
> >> the only allowed trespasser, for obvious reasons.)
> >
> > If you have MSYSGit installed, then resisting MSYS is kinda pointless,
> > don't you think?  Because you already have most of MSYS, and then
> > some.
> 
> AFAIK, MSYSGit lacks key components for running configure scripts.

The only one that's missing is make.exe.

> The POSIX build will require Windows-specific tweaks from time to time,
> which require knowledge about the POSIX build *and* about Windows.
> That's not much better than now.

I think it _is_ much better, because (a) the changes will be more
rare, and (b) the other maintainers will be able to help.  But
eventually, time will tell who is right (assuming this project
succeeds in making it to the repository).

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

> Is there any reason you needed a manifest for emacsclient?  Did you
> see elevation prompts or something?

When I try to build first, I thought that some error has occured about
it, but there is no error when I try now. Sorry, please ignore it.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> If USE_NO_MINGW_SETJMP_TWO_ARGS is defined, it seems that emacs crash
> when byte-compile. I do not know what happened in this case exactly,
> sorry.
> 
> In ms-w32.h, some functions are defined to sys_...,
> such as chmod -> sys_chmod.
> if it is defined before "#include <sys/stat.h>",
> functions in sys/stat.h are changed.
> It cause warning like "warning: 'sys_chmod' redeclared without
> dllimport...", I think. so I include it here.
> 
> __start is entry point that specified by linker option in makefile,
> but 64bit gcc does not add '_' to symbol, so change _start to
> __start.
> 
> >   --- ./nt/inc/sys/time.h.orig	2013-03-26 17:33:23.000000000 +0900
> >   +++ ./nt/inc/sys/time.h	2013-03-26 21:46:23.425698700 +0900
>     :
> > This breaks the MinGW32 build, so please see if the current trunk has
> > a better solution for this problem.
> 
> I understand.
> 
> >     --- ./src/image.c.orig	2013-03-24 18:16:45.000000000 +0900
> >     +++ ./src/image.c	2013-03-26 21:46:23.437698700 +0900
> >     @@ -5545,6 +5545,9 @@
> >        png_byte **rows;
> >      };
> >
> >     +#ifdef _W64
> >     +#define _setjmp setjmp
> >     +#endif
> >
> > Why is this needed?
> 
> In image.c, _setjmp() is used with 1 arg. It seems that some compile error.
> This is also related to the following.
> 
> >   --- ./src/lisp.h.orig	2013-03-25 12:31:37.000000000 +0900
> >   +++ ./src/lisp.h	2013-03-26 21:46:23.442698700 +0900
> >   @@ -2164,7 +2164,11 @@
> >
> >    #ifdef HAVE__SETJMP
> >    typedef jmp_buf sys_jmp_buf;
> >   +#ifdef _W64
> >   +# define sys_setjmp(j) setjmp (j)
> >   +#else
> >    # define sys_setjmp(j) _setjmp (j)
> >   +#endif
> >    # define sys_longjmp(j, v) _longjmp (j, v)
> >
> > And this?
> 
> If USE_NO_MINGW_SETJMP_TWO_ARGS is not defined,
> it seems that _setjmp() need 2 args (see mingw-w64's setjmp.h).
> so I change this.

I think I found a cleaner way of handling the MinGW64 setjmp
interface, committed as trunk revision 112145.

The 64-bit MinGW64 build still needs some changes, in nt/configure.bat
and elsewhere.  But I hope the 32-bit build is OK now.

Can you two please see if the latest trunk builds with MinGW64 for
you?  (Remember to re-run configure.bat, as some changes require
that.)  If there are any problems left, whether errors or warnings,
please post them.

TIA

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

> Can you two please see if the latest trunk builds with MinGW64 for
> you?  (Remember to re-run configure.bat, as some changes require
> that.)  If there are any problems left, whether errors or warnings,
> please post them.

OK. I tried revision 112145 (32-bit build).
Stopped with the following error.

        :
gcc -I. -c   -mtune=pentium4 -O2     -I/usr/local/32/gnutls/include -I/usr/local/32/librsvg/include/librsvg-2.0 -I/usr/local/32/librsvg/include/gdk-pixbuf-2.0 -I/usr/local/32/librsvg/include/glib-2.0 -I/usr/local/32/librsvg/lib/glib-2.0/include -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/editfns.o editfns.c
editfns.c: In function 'format_time_string':
editfns.c:1793:32: warning: pointer/integer type mismatch in conditional expression [enabled by default]
editfns.c: In function 'Fdecode_time':
editfns.c:1844:16: warning: assignment makes pointer from integer without a cast [enabled by default]
editfns.c: In function 'Fcurrent_time_string':
editfns.c:2011:6: warning: assignment makes pointer from integer without a cast [enabled by default]
gcc -I. -c   -mtune=pentium4 -O2     -I/usr/local/32/gnutls/include -I/usr/local/32/librsvg/include/librsvg-2.0 -I/usr/local/32/librsvg/include/gdk-pixbuf-2.0 -I/usr/local/32/librsvg/include/glib-2.0 -I/usr/local/32/librsvg/lib/glib-2.0/include -Demacs=1 -I../lib -I../nt/inc -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo-spd/i386/eval.o eval.c
eval.c: In function 'internal_catch':
eval.c:963:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
eval.c: In function 'internal_lisp_condition_case':
eval.c:1126:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
eval.c: In function 'internal_condition_case':
eval.c:1181:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
eval.c: In function 'internal_condition_case_1':
eval.c:1219:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
eval.c: In function 'internal_condition_case_2':
eval.c:1261:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
eval.c: In function 'internal_condition_case_n':
eval.c:1305:3: error: too few arguments to function '_setjmp'
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
makefile:343: recipe for target `oo-spd/i386/eval.o' failed
make[3]: *** [oo-spd/i386/eval.o] Error 1
make[3]: Leaving directory `/usr/local/src/emacs/w64/test/emacs/src'
makefile:597: recipe for target `bootstrap-temacs-SH' failed
make[2]: *** [bootstrap-temacs-SH] Error 2
make[2]: Leaving directory `/usr/local/src/emacs/w64/test/emacs/src'
makefile:600: recipe for target `bootstrap-temacs' failed
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `/usr/local/src/emacs/w64/test/emacs/src'
makefile:523: recipe for target `bootstrap-gmake' failed
make: *** [bootstrap-gmake] Error 2

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 27 Mar 2013 03:13:02 +0900
> 
> eval.c: In function 'internal_catch':
> eval.c:963:3: error: too few arguments to function '_setjmp'
> c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here
> eval.c: In function 'internal_lisp_condition_case':
> eval.c:1126:3: error: too few arguments to function '_setjmp'
> c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/setjmp.h:164:63: note: declared here

Thanks.  I'm probably missing something here, please help me see what
is it.  lisp.h says this:

  #ifdef HAVE__SETJMP
  typedef jmp_buf sys_jmp_buf;
  # define sys_setjmp(j) _setjmp (j)
  # define sys_longjmp(j, v) _longjmp (j, v)
  #elif defined HAVE_SIGSETJMP
  typedef sigjmp_buf sys_jmp_buf;
  # define sys_setjmp(j) sigsetjmp (j, 0)
  # define sys_longjmp(j, v) siglongjmp (j, v)
  #else
  /* A platform that uses neither _longjmp nor siglongjmp; assume
     longjmp does not affect the sigmask.  */
  typedef jmp_buf sys_jmp_buf;
  # define sys_setjmp(j) setjmp (j)
  # define sys_longjmp(j, v) longjmp (j, v)
  #endif

The latest trunk avoids defining HAVE__SETJMP for MinGW64, in
nt/config.nt (did you remember to run configure.bat?):

  /* Define to 1 if _setjmp and _longjmp work.  MinGW64 uses a
     2-argument _setjmp, and setjmp is a macro defined to supply the 2nd
     arg correctly, so don't use _setjmp directly in that case.  */
  #ifndef _W64
  #define HAVE__SETJMP 1
  #endif

And HAVE_SIGSETJMP is not defined in the MinGW build.  So the above
snippet from lisp.h should have define sys_setjmp as a call to setjmp,
not to _setjmp.  And setjmp is defined as follows on MinGW64's
setjmp.h header file:

  #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))

So why isn't this working? why eval.c somehow calls _setjmp with only
1 argument?

I also don't understand these 2 warnings:

  editfns.c: In function 'format_time_string':
  editfns.c:1793:32: warning: pointer/integer type mismatch in conditional expression [enabled by default]
  editfns.c: In function 'Fdecode_time':
  editfns.c:1844:16: warning: assignment makes pointer from integer without a cast [enabled by default]
  editfns.c: In function 'Fcurrent_time_string':
  editfns.c:2011:6: warning: assignment makes pointer from integer without a cast [enabled by default]

This sounds like the prototypes of gmtime and/or localtime are not
visible to the compiler at this point.  But how can that happen, when
ms-w32.h, included by config.h, includes time.h which declares these 2
functions?

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> The latest trunk avoids defining HAVE__SETJMP for MinGW64, in
> nt/config.nt (did you remember to run configure.bat?):
>
>   /* Define to 1 if _setjmp and _longjmp work.  MinGW64 uses a
>      2-argument _setjmp, and setjmp is a macro defined to supply the 2nd
>      arg correctly, so don't use _setjmp directly in that case.  */
>   #ifndef _W64
>   #define HAVE__SETJMP 1
>   #endif
>
> And HAVE_SIGSETJMP is not defined in the MinGW build.  So the above
> snippet from lisp.h should have define sys_setjmp as a call to setjmp,
> not to _setjmp.  And setjmp is defined as follows on MinGW64's
> setjmp.h header file:
>
>   #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
>
> So why isn't this working? why eval.c somehow calls _setjmp with only
> 1 argument?

While compiling eval.c, at the time config.h is preprocessed _W64 is
undefined because no MinGW header was #included yet.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 21:17:23 +0100
> 
> While compiling eval.c, at the time config.h is preprocessed _W64 is
> undefined because no MinGW header was #included yet.

Right you are.  Did revision 112146 fix that?

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> w32.c: In function 'readlink':
>> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
>> w32.c:4725:44: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this function)
>
> This got me puzzled: the definition of REPARSE_DATA_BUFFER is now
> guarded by this:
>
>  #ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE
>
> Are you saying that MAXIMUM_REPARSE_DATA_BUFFER_SIZE is defined in the
> MinGW64 build, but REPARSE_DATA_BUFFER is not?  Which MinGW64 headers
> define MAXIMUM_REPARSE_DATA_BUFFER_SIZE and REPARSE_DATA_BUFFER?

winnt.h defined MAXIMUM_REPARSE_DATA_BUFFER_SIZE. REPARSE_DATA_BUFFER is
defined in ddk/ntifs.h, but we shouldn't use that header together with
winnt.h. See the links in my message on this thread about ddk/ntifs.h:

http://permalink.gmane.org/gmane.emacs.devel/158160

BTW, the setjmp issue seems fixed.

Re: 64-bit port

[Fabrice Popineau]

cg <chengang31 <at> gmail.com> writes:

> Then I got the error in batch compiling the lisp code:
> 
> Dumping from obj/AMD64/temacs.bin
>            to obj/AMD64/temacs.exe
>          "X:\emacs_files\trunk\bzr64\src/obj/AMD64/temacs.exe" -batch -l 
> loadup bootstrap
> ...
> Loading loadup.el (source)...
> Using load-path (../lisp x:/emacs_files/trun
> Loading emacs-lisp/byte-run (source)...
> ...
> Loading international/mule-conf (source)...
> Invalid function: "DEAD"

Yuck! This error surfaces again.
I can compile the current trunk. 
I am bootstrapping it at the moment.
I wonder what triggers this error, because
it keeps striking back.

> 
> I am using VS2012, if that matters.

I'm compiling from the "Open VS2012 x64 Native Tools Command Prompt".

My compile flags :
ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -
Zp8 -W2 -O2 -GF -Gy -Gd $(DEBUG_FLAG)

I keep the symbols even when optimizing.

Fabrice

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 21:49:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> w32.c: In function 'readlink':
> >> w32.c:4725:7: error: unknown type name 'REPARSE_DATA_BUFFER'
> >> w32.c:4725:44: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this function)
> >
> > This got me puzzled: the definition of REPARSE_DATA_BUFFER is now
> > guarded by this:
> >
> >  #ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE
> >
> > Are you saying that MAXIMUM_REPARSE_DATA_BUFFER_SIZE is defined in the
> > MinGW64 build, but REPARSE_DATA_BUFFER is not?  Which MinGW64 headers
> > define MAXIMUM_REPARSE_DATA_BUFFER_SIZE and REPARSE_DATA_BUFFER?
> 
> winnt.h defined MAXIMUM_REPARSE_DATA_BUFFER_SIZE. REPARSE_DATA_BUFFER is
> defined in ddk/ntifs.h, but we shouldn't use that header together with
> winnt.h. See the links in my message on this thread about ddk/ntifs.h:
> 
> http://permalink.gmane.org/gmane.emacs.devel/158160

Then I guess we need to use _W64 explicitly, see revision 112147.

> BTW, the setjmp issue seems fixed.

Great.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Then I guess we need to use _W64 explicitly, see revision 112147.

Now emacs.exe is created. Bootstrap in progress.

When MinGW64 failed with Emacs I switched to VS, but it's nice to be
able to use gcc again.

Thank you.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Óscar Fuentes]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Then I guess we need to use _W64 explicitly, see revision 112147.
>
> Now emacs.exe is created. Bootstrap in progress.

There is one minor issue left:

gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/includ
e  -o oo-spd/i386/addpm.o addpm.c
In file included from addpm.c:46:0:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/shlobj.h:17:2: error: #error _WIN32_IE setting conflicts
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/shlobj.h:88:0,
                 from addpm.c:46:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/commctrl.h:17:2: error: #error _WIN32_IE setting conflicts
In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
.2/../../../../i686-w64-mingw32/include/shlobj.h:91:0,
                 from addpm.c:46:
c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts
mingw32-make[1]: *** [oo-spd/i386/addpm.o] Error 1
mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/nt'


As in a previous case, _W64 is checked for definition before _mingw.h is
(directly or indirectly) #included:

#ifndef _W64
#define _WIN32_IE 0x400
#endif

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 26 Mar 2013 23:30:55 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Then I guess we need to use _W64 explicitly, see revision 112147.
> >
> > Now emacs.exe is created. Bootstrap in progress.
> 
> There is one minor issue left:
> 
> gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2    -isystemc:/apps/GnuWin32/includ
> e  -o oo-spd/i386/addpm.o addpm.c
> In file included from addpm.c:46:0:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
> 4-mingw32/include/shlobj.h:17:2: error: #error _WIN32_IE setting conflicts
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
> .2/../../../../i686-w64-mingw32/include/shlobj.h:88:0,
>                  from addpm.c:46:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
> 4-mingw32/include/commctrl.h:17:2: error: #error _WIN32_IE setting conflicts
> In file included from c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7
> .2/../../../../i686-w64-mingw32/include/shlobj.h:91:0,
>                  from addpm.c:46:
> c:\apps\msys\1.0\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w6
> 4-mingw32/include/shlguid.h:16:2: error: #error _WIN32_IE setting conflicts
> mingw32-make[1]: *** [oo-spd/i386/addpm.o] Error 1
> mingw32-make[1]: Leaving directory `D:/dev/emacs/emacs/nt'
> 
> 
> As in a previous case, _W64 is checked for definition before _mingw.h is
> (directly or indirectly) #included:
> 
> #ifndef _W64
> #define _WIN32_IE 0x400
> #endif

Right.  Should be fixed now.

Are there any warnings left during MinGW64 compilation?  If so, please
post them.

Also, please try the --no-opt build, it uses slightly more strict
compiler switches, and might trigger warnings the optimized build
doesn't.

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

Sorry for late reply,

>   editfns.c: In function 'format_time_string':
>   editfns.c:1793:32: warning: pointer/integer type mismatch in conditional expression [enabled by default]
>   editfns.c: In function 'Fdecode_time':
>   editfns.c:1844:16: warning: assignment makes pointer from integer without a cast [enabled by default]
>   editfns.c: In function 'Fcurrent_time_string':
>   editfns.c:2011:6: warning: assignment makes pointer from integer without a cast [enabled by default]
>
> This sounds like the prototypes of gmtime and/or localtime are not
> visible to the compiler at this point.  But how can that happen, when
> ms-w32.h, included by config.h, includes time.h which declares these 2
> functions?

I found that localtime is defined to sys_localtime in ms-w32.h.
Because time.h is included before this definition, prototype is not
changed to sys_localtime.

When I move "#include <time.h>" after "#define localtime sys_localtime",
it seems that these warnings disappear.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 27 Mar 2013 17:17:38 +0900
> 
> Sorry for late reply,
> 
> >   editfns.c: In function 'format_time_string':
> >   editfns.c:1793:32: warning: pointer/integer type mismatch in conditional expression [enabled by default]
> >   editfns.c: In function 'Fdecode_time':
> >   editfns.c:1844:16: warning: assignment makes pointer from integer without a cast [enabled by default]
> >   editfns.c: In function 'Fcurrent_time_string':
> >   editfns.c:2011:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> >
> > This sounds like the prototypes of gmtime and/or localtime are not
> > visible to the compiler at this point.  But how can that happen, when
> > ms-w32.h, included by config.h, includes time.h which declares these 2
> > functions?
> 
> I found that localtime is defined to sys_localtime in ms-w32.h.
> Because time.h is included before this definition, prototype is not
> changed to sys_localtime.

Thanks.  Please try the latest trunk, I hope I fixed that.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

>> I found that localtime is defined to sys_localtime in ms-w32.h.
>> Because time.h is included before this definition, prototype is not
>> changed to sys_localtime.
>
> Thanks.  Please try the latest trunk, I hope I fixed that.

Thanks, this is fixed.
But, make bootstrap failed with the following error.

make[3]: *** No rule to make target `../nt/oo-spd/i386/addsection.exe', needed by `oo-spd/i386/temacs.exe'.  Stop.
make[3]: Leaving directory `/usr/local/src/emacs/w64/test/emacs/src'
makefile:597: recipe for target `bootstrap-temacs-SH' failed

I think that the changes for makefile.w32-in affect this.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Mar 2013 18:34:06 +0900
> 
> But, make bootstrap failed with the following error.
> 
> make[3]: *** No rule to make target `../nt/oo-spd/i386/addsection.exe', needed by `oo-spd/i386/temacs.exe'.  Stop.
> make[3]: Leaving directory `/usr/local/src/emacs/w64/test/emacs/src'
> makefile:597: recipe for target `bootstrap-temacs-SH' failed
> 
> I think that the changes for makefile.w32-in affect this.

I did bootstrap after those changes, and somehow it worked for me.

But you are right; please try again.  Sorry for the breakage.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

> But you are right; please try again.  Sorry for the breakage.

Thanks, it worked.

The remained warnings in my environment are below, it is same
with/without --no-opt.
The last two may be my environment problem.


w32.c:177:0: warning: "FSCTL_GET_REPARSE_POINT" redefined [enabled by default]
c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/winioctl.h:1270:0: note: this is the location of the previous definition

w32proc.c:45:20: warning: 'IsValidLocale' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]

gnutls.c:117:1: warning: 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]

image.c: In function 'my_png_error':
image.c:5482:1: warning: 'noreturn' function does return [enabled by default]

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 27 Mar 2013 20:35:51 +0900
> 
> The remained warnings in my environment are below, it is same
> with/without --no-opt.
> The last two may be my environment problem.
> 
> 
> w32.c:177:0: warning: "FSCTL_GET_REPARSE_POINT" redefined [enabled by default]
> c:\usr\local\strawberry-perl-5.16.3.1-32bit-portable\c\bin\../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/winioctl.h:1270:0: note: this is the location of the previous definition
> 
> w32proc.c:45:20: warning: 'IsValidLocale' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]

These two should be fixed in trunk revision 112156.

> gnutls.c:117:1: warning: 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]

Ted, could you please look into this?

> image.c: In function 'my_png_error':
> image.c:5482:1: warning: 'noreturn' function does return [enabled by default]

I don't see anything wrong with the code; could be a compiler bug.

Thanks.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

And, this is not important for me, when run configure.bat with --with-svg
can not compile image.c because DEF_IMGLIB_FN macro is used with 2 args
for svg but current DEF_IMGLIB_FN macro is defined as 3 args macro.
No one use this?

using GnuTLS 3.x and certificate checks (was: Anyone building Emacs trunk with MinGW w64 (32 bits))

[Ted Zlatanov]

On Wed, 27 Mar 2013 14:03:59 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> gnutls.c:117:1: warning: 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]

EZ> Ted, could you please look into this?

This function was deprecated in GnuTLS 2.99.

3.1.10 is the latest.  I used 2.x when I did the GnuTLS support, but by
now 3.x is much more widely distributed so I think we can switch to it.
Fortunately, the changes will be minimal because the API hasn't changed
significantly AFAIK.  So this is mostly a policy decision.

At least in Ubuntu 12.10, GnuTLS 3.x is the default.  I know it's
already what people use on W32 and MacOS X.  What about other platforms?
Any concerns?

This would also be a good time to enable SSL certificate verification by
default.  We said we'd wait until 24.3 is out to make that change.

Ted

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 27 Mar 2013 21:57:55 +0900
> 
> And, this is not important for me, when run configure.bat with --with-svg
> can not compile image.c because DEF_IMGLIB_FN macro is used with 2 args
> for svg but current DEF_IMGLIB_FN macro is defined as 3 args macro.

Thanks, fixed.

> No one use this?

Probably.  Is librsvg stable enough on Windows to recommend it to
users?  Right now, nt/INSTALL has reservations about its stability.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[rzl24ozi]

>> And, this is not important for me, when run configure.bat with --with-svg
>> can not compile image.c because DEF_IMGLIB_FN macro is used with 2 args
>> for svg but current DEF_IMGLIB_FN macro is defined as 3 args macro.
>
> Thanks, fixed.

Thanks, but I cannot compile image.c still because
DEF_IMGLIB_FN (void, g_error_free, (GError *));
is missing.

>> No one use this?
>
> Probably.  Is librsvg stable enough on Windows to recommend it to
> users?  Right now, nt/INSTALL has reservations about its stability.

I see. I'm not sure it is stable enough because I never used it only
about to try to view etc/images/splash.svg.

Re: Anyone building Emacs trunk with MinGW w64 (32 bits)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Thu, 28 Mar 2013 07:03:27 +0900
> 
> Thanks, but I cannot compile image.c still because
> DEF_IMGLIB_FN (void, g_error_free, (GError *));
> is missing.

Added it.

Re: using GnuTLS 3.x and certificate checks

[Christopher Schmidt]

Ted Zlatanov <tzz@lifelogs.com> writes:
> This would also be a good time to enable SSL certificate verification
> by default.

That's a great idea.

What do you think about a user-customizable verification mechanism?
This could be as simple as passing host, port and the PEM-encoded cert
chain to a regular function that will return non-nil if the verification
failed.

        Christopher

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Wed, 10 Apr 2013 21:35:18 +0100 (BST) Christopher Schmidt <christopher@ch.ristopher.com> wrote: 

CS> Ted Zlatanov <tzz@lifelogs.com> writes:
>> This would also be a good time to enable SSL certificate verification
>> by default.

CS> That's a great idea.

CS> What do you think about a user-customizable verification mechanism?
CS> This could be as simple as passing host, port and the PEM-encoded cert
CS> chain to a regular function that will return non-nil if the verification
CS> failed.

I like your idea, the problem is that often it will be triggered at very
inconvenient times.  Emacs, unlike most other environments with this
capability, doesn't deal well with interrupting network I/O to ask the
user questions... not to mention the TCP exchange itself could be
aborted, or the whole thing could be running unattended (--batch for
example).

I think Lars and many others have brought up these issues before, mostly
on the bug tracker over the last year or two.

To start the planning, is there a way to tell Emacs "run this function,
but if we're not interactive or if the user has not answered in 30
seconds, proceed as if they answered 'n' to everything"?  I think that
would be better than writing special code just for GnuTLS.  But I'm open
to suggestions either way.

Ted

Re: using GnuTLS 3.x and certificate checks

[Christopher Schmidt]

Ted Zlatanov <tzz@lifelogs.com> writes:
> I like your idea, the problem is that often it will be triggered at
> very inconvenient times.  Emacs, unlike most other environments with
> this capability, doesn't deal well with interrupting network I/O to
> ask the user questions... not to mention the TCP exchange itself could
> be aborted, or the whole thing could be running unattended (--batch
> for example).

I think a verification mechanism should run unattended without user
interaction whatsoever.  What's your use case for an interactive
verification snippet?

        Christopher

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Sun, 19 May 2013 20:34:15 +0100 (BST) Christopher Schmidt <christopher@ch.ristopher.com> wrote: 

CS> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I like your idea, the problem is that often it will be triggered at
>> very inconvenient times.  Emacs, unlike most other environments with
>> this capability, doesn't deal well with interrupting network I/O to
>> ask the user questions... not to mention the TCP exchange itself could
>> be aborted, or the whole thing could be running unattended (--batch
>> for example).

CS> I think a verification mechanism should run unattended without user
CS> interaction whatsoever.  What's your use case for an interactive
CS> verification snippet?

How else could a user accept a previously unknown certificate?

Ted

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Sun, 19 May 2013 18:59:01 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sun, 19 May 2013 20:34:15 +0100 (BST) Christopher Schmidt <christopher@ch.ristopher.com> wrote: 
CS> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I like your idea, the problem is that often it will be triggered at
>>> very inconvenient times.  Emacs, unlike most other environments with
>>> this capability, doesn't deal well with interrupting network I/O to
>>> ask the user questions... not to mention the TCP exchange itself could
>>> be aborted, or the whole thing could be running unattended (--batch
>>> for example).

CS> I think a verification mechanism should run unattended without user
CS> interaction whatsoever.  What's your use case for an interactive
CS> verification snippet?

TZ> How else could a user accept a previously unknown certificate?

Ping?  Any ideas?

Ted

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Sat, 18 May 2013 22:57:31 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> To start the planning, is there a way to tell Emacs "run this function,
TZ> but if we're not interactive or if the user has not answered in 30
TZ> seconds, proceed as if they answered 'n' to everything"?  I think that
TZ> would be better than writing special code just for GnuTLS.  But I'm open
TZ> to suggestions either way.

Ping?  I'd like to get started on this but need ideas and suggestions.

Ted

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Wed, 27 Mar 2013 09:17:38 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 27 Mar 2013 14:03:59 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>>> gnutls.c:117:1: warning: 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]

EZ> Ted, could you please look into this?

TZ> This function was deprecated in GnuTLS 2.99.

TZ> 3.1.10 is the latest.  I used 2.x when I did the GnuTLS support, but by
TZ> now 3.x is much more widely distributed so I think we can switch to it.
TZ> Fortunately, the changes will be minimal because the API hasn't changed
TZ> significantly AFAIK.  So this is mostly a policy decision.

TZ> At least in Ubuntu 12.10, GnuTLS 3.x is the default.  I know it's
TZ> already what people use on W32 and MacOS X.  What about other platforms?
TZ> Any concerns?

TZ> This would also be a good time to enable SSL certificate verification by
TZ> default.  We said we'd wait until 24.3 is out to make that change.

Without comments, I will assume a general OK on these two things:

- move to the GnuTLS 3.x API and require that version of the libraries.

- enable SSL certificate verification by default (I have some questions
  about non-interactive cases in a separate thread).

Ted

Re: using GnuTLS 3.x and certificate checks

[Christopher Schmidt]

Ted Zlatanov <tzz@lifelogs.com> writes:
> CS> I think a verification mechanism should run unattended without
> CS> user interaction whatsoever.  What's your use case for an
> CS> interactive verification snippet?
>
> TZ> How else could a user accept a previously unknown certificate?
>
> Ping?  Any ideas?

I don't know.  I don't think there is a common use case, though.

Those folks who set up their own verification or pinning mechanism in
favour of a ca-certificates.crt provided by the operating system usually
apply extra careful scrutiny and caution on all aspects of the
certificates.  Accepting new certificates on-the-fly via interactive
minibuffer queries is not a good idea.  I assume most folks would want
to abort the handshake and take a look at the full dump of all the certs
in the chain.

Check the Screenshots of Certificate Patrol.

    https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

I, for one, don't need or want any interactive query in case
verification fails.  An user-error or returning an error status is
enough.  (I already implemented certificate pinning support by
substituting open-network-stream with my own implementation.  If
verification fails, the cert's received are printed to the
*Messages*-buffer and the connection is killed.  My investigations
continues outside Emacs with the help of gnutls-cli --print-cert and
certtool.  This system is easy to maintain, does not cause much trouble
and I don't have any complains so far.)

        Christopher

Re: using GnuTLS 3.x and certificate checks

[Stefan Monnier]

TZ> To start the planning, is there a way to tell Emacs "run this function,
TZ> but if we're not interactive or if the user has not answered in 30
TZ> seconds, proceed as if they answered 'n' to everything"?  I think that
TZ> would be better than writing special code just for GnuTLS.  But I'm open
TZ> to suggestions either way.

> Ping?  I'd like to get started on this but need ideas and suggestions.

I don't understand the question, and/or the need for it.


        Stefan

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Wed, 05 Jun 2013 13:44:55 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

TZ> To start the planning, is there a way to tell Emacs "run this function,
TZ> but if we're not interactive or if the user has not answered in 30
TZ> seconds, proceed as if they answered 'n' to everything"?  I think that
TZ> would be better than writing special code just for GnuTLS.  But I'm open
TZ> to suggestions either way.

>> Ping?  I'd like to get started on this but need ideas and suggestions.

SM> I don't understand the question, and/or the need for it.

When interactive, you should be asked if you want to accept a SSL
certificate unless your function pre-approves it.  So the default
interactively is 'maybe-ask.  The other question is, if the user
doesn't answer in 30 seconds, can we take that as a "no" answer?  I
think the answer is "no, just wait for it."

When non-interactive, you can't be asked.  So the default there can be
'maybe-ask (what I describe in my question, and make it fail gracefully)
or 'maybe-reject (unless pre-approved, reject).  It sounds like no one
wants 'maybe-ask non-interactively.

Ted

Re: using GnuTLS 3.x and certificate checks

[Stefan Monnier]

> When interactive, you should be asked if you want to accept a SSL
> certificate unless your function pre-approves it.  So the default
> interactively is 'maybe-ask.  The other question is, if the user
> doesn't answer in 30 seconds, can we take that as a "no" answer?  I
> think the answer is "no, just wait for it."

By default it makes sense to prompt the user, and if she's not available
to reply, just wait until she is.  No need for any special functionality.

> When non-interactive, you can't be asked.  So the default there can be
> 'maybe-ask (what I describe in my question, and make it fail gracefully)
> or 'maybe-reject (unless pre-approved, reject).  It sounds like no one
> wants 'maybe-ask non-interactively.

In batch mode, prompting doesn't make much sense, so better default to
signal an error.


        Stefan

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Wed, 05 Jun 2013 11:13:18 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Without comments, I will assume a general OK on these two things:

TZ> - move to the GnuTLS 3.x API and require that version of the libraries.

TZ> - enable SSL certificate verification by default (I have some questions
TZ>   about non-interactive cases in a separate thread).

...and after Stefan's comments:

- SSL certificates will be run through a user-supplied acceptance
  function/regex/whatever.  If they are not accepted by it, the behavior
  forks.  In batch mode, we always refuse to accept.  In interactive
  mode, we do yes/no/save prompting, waiting forever.  Saving the
  certificate will put it in ~/.emacs.d/certificates or something
  similar.

  The interactive behavior may have a connection time out while waiting,
  which will cause surprises.  We'll try to reopen the connection but
  the user may not enjoy the experience and it could get refused the
  second time and so on.

Ted

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Wed, 05 Jun 2013 16:55:39 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 05 Jun 2013 11:13:18 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> Without comments, I will assume a general OK on these two things:

TZ> - move to the GnuTLS 3.x API and require that version of the libraries.

TZ> - enable SSL certificate verification by default (I have some questions
TZ> about non-interactive cases in a separate thread).

TZ> ...and after Stefan's comments:

TZ> - SSL certificates will be run through a user-supplied acceptance
TZ>   function/regex/whatever.  If they are not accepted by it, the behavior
TZ>   forks.  In batch mode, we always refuse to accept.  In interactive
TZ>   mode, we do yes/no/save prompting, waiting forever.  Saving the
TZ>   certificate will put it in ~/.emacs.d/certificates or something
TZ>   similar.

TZ>   The interactive behavior may have a connection time out while waiting,
TZ>   which will cause surprises.  We'll try to reopen the connection but
TZ>   the user may not enjoy the experience and it could get refused the
TZ>   second time and so on.

...adding Christopher Schmidt's comments to the last item:

The user will also have an option to reject by default interactively, to
inspect the offered certificate, and so on.  Basically the choice will
be this alist:

'((interactive . x)
  (non-interactive . y))

where x and y can be:

'ask => prompt y/n/Y (permanent)/N (permanent)/inspect
'maybe-reject => goes through the acceptance function and rejects if it fails
nil => always reject unknown
t => always accept, good for testing but discouraged otherwise

The symbols may evolve to specify the acceptance function inline.  The
default will probably be

'((interactive ask)
  (non-interactive maybe-reject))

I hope that's helpful :)

Ted

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

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

On Wed, 05 Jun 2013 11:13:18 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> Without comments, I will assume a general OK on these two things:

TZ> - move to the GnuTLS 3.x API and require that version of the libraries.

Related to this discussion and to bug#14774 (audit_log function, which
is only in GnuTLS 3.x)...

I found that many platforms are still on GnuTLS 2.x.  Unfortunately I
think we should keep compatibility with 2.x for a while longer and make
the 3.x features optional.  I hate that ambiguity and testing is made
harder, but OTOH we would keep supporting many users.

Here's a simple patch that finds GnuTLS 3.x and sets HAVE_GNUTLS3.  In
that case we set the audit_log function; otherwise we keep
compatibility.  Note the configure message that GnuTLS 3.x is highly
recommended.

Let me know what you think and if I should be more forceful here.  If I
should keep the compatibility path I will also add a
`gnutls-library-version' string variable so ELisp code can use it and
start moving on the tasks listed in this thread.

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnutlsv3.patch --]
[-- Type: text/x-diff, Size: 3889 bytes --]

=== modified file 'configure.ac'
--- configure.ac	2013-09-25 03:44:34 +0000
+++ configure.ac	2013-10-07 21:11:24 +0000
@@ -2425,12 +2425,18 @@
 AC_SUBST(LIBSELINUX_LIBS)
 
 HAVE_GNUTLS=no
+HAVE_GNUTLS3=no
 if test "${with_gnutls}" = "yes" ; then
   PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.6.6], HAVE_GNUTLS=yes, HAVE_GNUTLS=no)
+  PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 3.0.0], HAVE_GNUTLS3=yes, HAVE_GNUTLS3=no)
   if test "${HAVE_GNUTLS}" = "yes"; then
     AC_DEFINE(HAVE_GNUTLS, 1, [Define if using GnuTLS.])
   fi
 
+  if test "${HAVE_GNUTLS3}" = "yes"; then
+    AC_DEFINE(HAVE_GNUTLS3, 1, [Define if using GnuTLS v3.])
+  fi
+
   # Windows loads GnuTLS dynamically
   if test "${opsys}" = "mingw32"; then
     LIBGNUTLS_LIBS=
@@ -4934,6 +4940,7 @@
 echo "  Does Emacs use access control lists?                    ${acl_summary}"
 echo "  Does Emacs use -lselinux?                               ${HAVE_LIBSELINUX}"
 echo "  Does Emacs use -lgnutls?                                ${HAVE_GNUTLS}"
+echo "  Does Emacs use -lgnutls v3 (HIGHLY RECOMMENDED)?        ${HAVE_GNUTLS3}"
 echo "  Does Emacs use -lxml2?                                  ${HAVE_LIBXML2}"
 
 echo "  Does Emacs use -lfreetype?                              ${HAVE_FREETYPE}"

=== modified file 'src/gnutls.c'
--- src/gnutls.c	2013-01-02 16:13:04 +0000
+++ src/gnutls.c	2013-10-07 22:14:55 +0000
@@ -55,6 +55,7 @@
 static Lisp_Object QCgnutls_bootprop_callbacks_verify;
 
 static void gnutls_log_function (int, const char *);
+static void gnutls_audit_log_function (gnutls_session_t, const char *);
 static void gnutls_log_function2 (int, const char*, const char*);
 
 \f
@@ -108,6 +109,9 @@
 DEF_GNUTLS_FN (int, gnutls_error_is_fatal, (int));
 DEF_GNUTLS_FN (int, gnutls_global_init, (void));
 DEF_GNUTLS_FN (void, gnutls_global_set_log_function, (gnutls_log_func));
+#ifdef HAVE_GNUTLS3
+DEF_GNUTLS_FN (void, gnutls_global_set_audit_log_function, (gnutls_audit_log_func));
+#endif
 DEF_GNUTLS_FN (void, gnutls_global_set_log_level, (int));
 DEF_GNUTLS_FN (void, gnutls_global_set_mem_functions,
 	       (gnutls_alloc_function, gnutls_alloc_function,
@@ -173,6 +177,9 @@
   LOAD_GNUTLS_FN (library, gnutls_error_is_fatal);
   LOAD_GNUTLS_FN (library, gnutls_global_init);
   LOAD_GNUTLS_FN (library, gnutls_global_set_log_function);
+#ifdef HAVE_GNUTLS3
+  LOAD_GNUTLS_FN (library, gnutls_global_set_audit_log_function);
+#endif
   LOAD_GNUTLS_FN (library, gnutls_global_set_log_level);
   LOAD_GNUTLS_FN (library, gnutls_global_set_mem_functions);
   LOAD_GNUTLS_FN (library, gnutls_handshake);
@@ -230,6 +237,9 @@
 #define fn_gnutls_error_is_fatal		gnutls_error_is_fatal
 #define fn_gnutls_global_init			gnutls_global_init
 #define fn_gnutls_global_set_log_function	gnutls_global_set_log_function
+#ifdef HAVE_GNUTLS3
+#define fn_gnutls_global_set_audit_log_function	gnutls_global_set_audit_log_function
+#endif
 #define fn_gnutls_global_set_log_level		gnutls_global_set_log_level
 #define fn_gnutls_global_set_mem_functions	gnutls_global_set_mem_functions
 #define fn_gnutls_handshake			gnutls_handshake
@@ -249,6 +259,16 @@
 #endif /* !WINDOWSNT */
 
 \f
+/* Function to log a simple audit message.  */
+static void
+gnutls_audit_log_function (gnutls_session_t session, const char* string)
+{
+  if (global_gnutls_log_level >= 1)
+    {
+      message ("gnutls.c: [audit] %s", string);
+    }
+}
+
 /* Function to log a simple message.  */
 static void
 gnutls_log_function (int level, const char* string)
@@ -797,6 +817,9 @@
   if (TYPE_RANGED_INTEGERP (int, loglevel))
     {
       fn_gnutls_global_set_log_function (gnutls_log_function);
+#ifdef HAVE_GNUTLS3
+      fn_gnutls_global_set_audit_log_function (gnutls_audit_log_function);
+#endif
       fn_gnutls_global_set_log_level (XINT (loglevel));
       max_log_level = XINT (loglevel);
       XPROCESS (proc)->gnutls_log_level = max_log_level;

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Mon, 07 Oct 2013 18:24:39 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I found that many platforms are still on GnuTLS 2.x.  Unfortunately I
TZ> think we should keep compatibility with 2.x for a while longer and make
TZ> the 3.x features optional.  I hate that ambiguity and testing is made
TZ> harder, but OTOH we would keep supporting many users.

TZ> Here's a simple patch that finds GnuTLS 3.x and sets HAVE_GNUTLS3.  In
TZ> that case we set the audit_log function; otherwise we keep
TZ> compatibility.  Note the configure message that GnuTLS 3.x is highly
TZ> recommended.

TZ> Let me know what you think and if I should be more forceful here.  If I
TZ> should keep the compatibility path I will also add a
TZ> `gnutls-library-version' string variable so ELisp code can use it and
TZ> start moving on the tasks listed in this thread.

Last chance to comment...  I will commit the change tomorrow if there
are no objections.

Ted

Re: using GnuTLS 3.x and certificate checks

[Glenn Morris]

Ted Zlatanov wrote:

>  echo "  Does Emacs use -lgnutls?                                ${HAVE_GNUTLS}"
> +echo "  Does Emacs use -lgnutls v3 (HIGHLY RECOMMENDED)?        ${HAVE_GNUTLS3}"

I dislike that message appearing there, plus it's misleading (in that I
guess you meant: if you are using Emacs with GnuTLS, then V3 is highly
recommended; rather than: everybody using Emacs for anything is strongly
recommended to build it with GnuTLS v3).

If you really feel strongly about it, how about ignoring (with a warning
at detection time) GnuTLS < 3 unless "--with-old-gnutls" (or somesuch)
is explicitly specified?

Re: using GnuTLS 3.x and certificate checks

[Ted Zlatanov]

On Thu, 10 Oct 2013 19:37:36 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> echo "  Does Emacs use -lgnutls?                                ${HAVE_GNUTLS}"
>> +echo "  Does Emacs use -lgnutls v3 (HIGHLY RECOMMENDED)?        ${HAVE_GNUTLS3}"

GM> I dislike that message appearing there, plus it's misleading (in that I
GM> guess you meant: if you are using Emacs with GnuTLS, then V3 is highly
GM> recommended; rather than: everybody using Emacs for anything is strongly
GM> recommended to build it with GnuTLS v3).

GM> If you really feel strongly about it, how about ignoring (with a warning
GM> at detection time) GnuTLS < 3 unless "--with-old-gnutls" (or somesuch)
GM> is explicitly specified?

You're right about the message, that's the wrong place and form.

Pushed without that detail (the configure output is the same as before).

Thanks
Ted