bug#9960: Compiling Emacs trunk with MSVC

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

See

  http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00213.html

and the rest of that thread for the initial discussion and patches by
Fabrice.

The essence of this bug report is that Emacs development trunk does
not compile with latest versions of MSVC.

What follows is discussion of some of the changes suggested by
Fabrice, including the description of how they were adapted to the
current trunk, and the diffs that will be actually committed shortly.

> +#ifdef _MSC_VER
> +  unsigned short redirect : 3;
> +#else
>    enum symbol_redirect redirect : 3;
> +#endif

I used a macro ENUM_BF, shamelessly stolen from GDB, to work around
this and other similar issues with enumerated types in bitfields.
This solution was suggested by the discussion in the above thread.

> --- ..\mirror\emacs-bzr\trunk\src/makefile.w32-in	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\src/makefile.w32-in	2010-12-13 21:48:10.000000000 +0100
> @@ -303,14 +303,14 @@
>  	$(MAKE) $(MFLAGS) TAGS-LISP-$(MAKETYPE)
> 
>  TAGS-gmake:
> -	../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \
> -	  --regex=@../nt/emacs-src.tags \
> -	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> -	../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
> -	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> -	../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
> -	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> -	  $(CURDIR)/*.h
> +# ../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \
> +#   --regex=@../nt/emacs-src.tags \
> +#   $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> +# ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
> +#   $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> +# ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
> +#   $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> +#   $(CURDIR)/*.h

This was fixed by hiding the use of $patsubst in nt/gmake.defs, so
only a build that uses GNU Make will see that.

> --- ..\mirror\emacs-bzr\trunk\src/s/ms-w32.h	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\src/s/ms-w32.h	2010-12-13 23:20:18.000000000 +0100
> @@ -208,6 +218,9 @@
>  #undef dup2
>  #define dup2    sys_dup2
>  #define fopen   sys_fopen
> +#if 1
> +#define fstat(a, b)   sys_fstat(a, b)
> +#endif
>  #define link    sys_link
>  #define mkdir   sys_mkdir
>  #undef mktemp
> @@ -221,9 +234,13 @@
>  #define rmdir   sys_rmdir
>  #define select  sys_select
>  #define sleep   sys_sleep
> +#if 1
> +#define stat(a, b)   sys_stat(a, b)
> +#endif
>  #define strerror sys_strerror
>  #undef unlink
>  #define unlink  sys_unlink
> +#define utime   sys_utime

These and other similar changes were added, but conditioned on
_MSC_VER, so as to avoid any possible adverse effects on MinGW builds,
since we are in a pretest.  (I don't see any adverse effects, but I'd
like to err on the safe side.)

> -      if (tmp && _access (tmp, D_OK) == 0)
> +      if (tmp && sys_access (tmp, D_OK) == 0)

Again, added only for MSVC, for the same reasons.

> +#define stringer( x ) ( #x )
> +
>  char *
>  get_emacs_configuration_options (void)
>  {
> @@ -1900,10 +1905,10 @@
>      /* configure.bat already sets USER_CFLAGS and USER_LDFLAGS
>         with a starting space to save work here.  */
>  #ifdef USER_CFLAGS
> -    " --cflags", USER_CFLAGS,
> +    " --cflags", stringer(USER_CFLAGS),
>  #endif
>  #ifdef USER_LDFLAGS
> -    " --ldflags", USER_LDFLAGS,
> +    " --ldflags", stringer(USER_LDFLAGS),
>  #endif
>      NULL
>    };

I didn't do anything with this issue.  Fabrice wrote further down the
thread:

> > -    " --cflags", USER_CFLAGS,
> > > +    " --cflags", stringer(USER_CFLAGS),
> >
> > Why did you need to stringify here?  USER_CFLAGS is supposed to be
> > defined to a quoted string, like " -DFOO".  Can you tell why this
> > didn't work for you?
> 
> 
> Oops. I used this hack long ago, and I reintroduced it. But my real problem
> is that user_cflags contains
> various -I<path> to find include files, and these paths have \ that are not
> doubled.
> Stringifying is a bad idea and doesn't solve the problem at all. Need to
> find a better solution.

One possibility of a "better solution" would be to use only forward
slashes in user_cflags, as nt/INSTALL already tells.  Fabrice, will
this work with MSVC?  We already use "-I../something", so I hope this
can be the solution.

> --- ..\mirror\emacs-bzr\trunk\lib-src/movemail.c	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\lib-src/movemail.c	2010-12-13 23:21:27.000000000 +0100
> @@ -164,6 +164,10 @@
>  /* Nonzero means this is name of a lock file to delete on fatal error.  */
>  char *delete_lockname;
> 
> +#ifdef _MSC_VER
> +typedef int ssize_t;
> +#endif

Moved to src/s/ms-w32.h, as Emacs uses ssize_t in other places now.

> --- ..\mirror\emacs-bzr\trunk\nt/configure.bat	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\nt/configure.bat	2010-12-13 16:10:24.000000000 +0100
> @@ -294,6 +294,18 @@
>  rem   Auto-detect compiler if not specified, and validate GCC if chosen.
> 
>  :checkcompiler
> +
> +rem set SDK environment
> +if (%noopt%) == (Y) (
> +   call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Debug
> +   set nodebug=N
> +)
> +
> +if (%nodebug%) == (Y) (
> +   call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Release
> +   set noopt=N
> +)
> +

I don't see a clean and safe way of incorporating this into
configure.bat.  Instead, I added some text to nt/INSTALL telling
people to run SetEnv.cmd as appropriate, with the above 2 lines as
examples.  I hope this is sufficient; we already had a similar advice
there for Visual Studio .NET.

> --- ..\mirror\emacs-bzr\trunk\nt/makefile.w32-in	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\nt/makefile.w32-in	2010-12-13 21:43:45.000000000 +0100
> @@ -36,6 +36,7 @@
> 
>  .PHONY: $(ALL)
> 
> +ARCH_CFLAGS	= $(ARCH_CFLAGS) -I../nt/inc -I../src

I don't understand why is this necessary, especially since nmake.defs
already adds these flags to CFLAGS.  So I didn't add these flags.

>  frc:
>  TAGS-gmake: frc
> -	../lib-src/$(BLD)/etags $(CURDIR)/*.c
> -	$(MAKE) $(MFLAGS) -C ../src TAGS TAGS-LISP
> -	$(MAKE) $(MFLAGS) -C ../lib-src TAGS
> +# ../lib-src/$(BLD)/etags $(CURDIR)/*.c
> +# $(MAKE) $(MFLAGS) -C ../src TAGS TAGS-LISP
> +# $(MAKE) $(MFLAGS) -C ../lib-src TAGS

I don't see any problem here, so I didn't make this change.  If there
is a real problem, please explain what it is.

> --- ..\mirror\emacs-bzr\trunk\nt/nmake.defs	2010-11-18 08:53:04.000000000 +0100
> +++ emacs-gnu\nt/nmake.defs	2010-12-13 16:13:22.000000000 +0100
> @@ -110,7 +110,13 @@
>  RC_OUT		= -Fo
>  RC_INCLUDE	= -i
> 
> -libc		= libc.lib
> +!ifdef USE_CRT_DLL
> +libc		= msvcrt$(D).lib
> +XCFLAGS		= -I../nt/inc -I../src -D_DLL -D_MT -DUSE_CRT_DLL=1
> +!else
> +libc		= libcmt$(D).lib
> +XCFLAGS		= -I../nt/inc -I../src -D_MT
> +!endif
>  baselibs	=

I modified EMACS_EXTRA_C_FLAGS accordingly, instead of introducing
XCFLAGS.

> -SYS_LDFLAGS	= -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
> +!ifdef NOOPT
> +SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -debug -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
> +!else
> +SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
> +!endif

I made these changes, but left the old SYS_LDFLAGS as a comment, in
case older versions of MSVC don't grok the new switches.

> -ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
> +ARCH_CFLAGS     = -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd $(DEBUG_FLAG)
>  !else
> -ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
> +ARCH_CFLAGS     = -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Oi -Ot -Oy- -Ob2 -GF -Gy -Gd $(DEBUG_FLAG)

Likewise.

> Also, note that to copile the whole thing, I need to run :
> 
> nmake USE_CRT_DLL=1

I modified nmake.defs to define USE_CRT_DLL=1 unconditionally, I hope
this will take care of that.

The actual diffs I'm about to commit are below.  Fabrice, I'd
appreciate if you could check out the latest trunk, after these are
committed, and test it.  I attach the diffs below in case you would
want to try this on the version on which you worked a year ago
(because a lot has been changed in Emacs since then, and maybe the new
stuff needs further patches).

Thanks in advance.

------------------------------------------------------------

=== modified file 'lib/makefile.w32-in'
--- lib/makefile.w32-in	2011-07-24 22:15:47 +0000
+++ lib/makefile.w32-in	2011-11-05 10:02:34 +0000
@@ -50,7 +50,9 @@ all:		stamp_BLD $(ALL)
 
 ### TAGS ###
 
-TAGS:
+FRC:
+
+TAGS: FRC
 	 ../lib-src/$(BLD)/etags.exe *.c *.h
 
 ### DEPENDENCIES ###

=== modified file 'nt/INSTALL'
--- nt/INSTALL	2011-10-25 02:33:24 +0000
+++ nt/INSTALL	2011-11-05 09:30:33 +0000
@@ -21,19 +21,32 @@
 
        cd nt
 
-  2. Run configure.bat.  From the COMMAND.COM/CMD.EXE command prompt:
+  2. Run configure.bat.
+
+  2a.If you use MSVC, set up the build environment by running the
+     SetEnv.cmd batch file from the appropriate SDK directory.  (Skip
+     this step if you are using MinGW.)  For example:
+
+       "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /Debug
+
+      if you are goiung to compile a debug version, or
+
+       "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /Release
+
+      if you are going to compile an optimized version.
+
+  2b.From the COMMAND.COM/CMD.EXE command prompt type:
 
        configure
 
-     from a Unixy shell prompt:
+     From a Unixy shell prompt:
 
        cmd /c configure.bat
      or
        command.com /c configure.bat
 
   3. Run the Make utility suitable for your environment.  If you build
-     with the Microsoft's Visual C compiler (but see notes about using
-     VC++ 8.0 and later below):
+     with the Microsoft's Visual C compiler:
 
        nmake
 
@@ -101,24 +114,21 @@
 * Supported development environments
 
   To compile Emacs, you will need either Microsoft Visual C++ 2.0, or
-  later up to 7.0, and nmake, or a Windows port of GCC 2.95 or later
-  with MinGW and W32 API support and a port of GNU Make.  You can use
-  the Cygwin ports of GCC, but Emacs requires the MinGW headers and
-  libraries to build (latest versions of the Cygwin toolkit, at least
-  since v1.3.3, include the MinGW headers and libraries as an integral
-  part).
-
-  Note that building Emacs with Visual Studio 2005 (VC++ 8.0) and
-  later is not supported at this time, due to changes introduced by
-  Microsoft into the libraries shipped with the compiler.
+  later and nmake, or a Windows port of GCC 2.95 or later with MinGW
+  and W32 API support and a port of GNU Make.  You can use the Cygwin
+  ports of GCC, but Emacs requires the MinGW headers and libraries to
+  build (latest versions of the Cygwin toolkit, at least since v1.3.3,
+  include the MinGW headers and libraries as an integral part).
 
   The rest of this file assumes you have a working development
-  environment.  If you just installed  such an environment, try
+  environment.  If you just installed such an environment, try
   building a trivial C "Hello world" program, and see if it works.  If
   it doesn't work, resolve that problem first!  If you use Microsoft
   Visual Studio .NET 2003, don't forget to run the VCVARS32.BAT batch
   file from the `Bin' subdirectory of the directory where you have
-  installed VS.NET.
+  installed VS.NET.  With other versions of MSVC, run the SetEnv.cmd
+  batch file from the `Bin' subdirectory of the directory where you
+  have the SDK installed.
 
   If you use the MinGW port of GCC and GNU Make to build Emacs, there
   are some compatibility issues wrt Make and the shell that is run by

=== modified file 'nt/gmake.defs'
--- nt/gmake.defs	2011-05-07 04:00:12 +0000
+++ nt/gmake.defs	2011-11-05 08:54:22 +0000
@@ -193,6 +193,11 @@ OLE32		= -lole32
 UNISCRIBE	= -lusp10
 UUID		= -luuid
 
+# Used by src/makefile.w32-in, since Nmake barfs on $(func SOMETHING)
+OBJ0_c		= $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
+OBJ1_c		= $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
+OBJ2_c		= $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2))
+
 ifdef NOOPT
 DEBUG_CFLAGS	= -DEMACSDEBUG
 else

=== modified file 'nt/makefile.w32-in'
--- nt/makefile.w32-in	2011-10-31 02:25:01 +0000
+++ nt/makefile.w32-in	2011-11-05 09:43:08 +0000
@@ -313,15 +313,15 @@ clean-other-dirs-nmake:
 	$(MAKE) $(MFLAGS) clean
 	cd ..\doc\lispintro
 	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\lispref
+	cd ..\lispref
 	$(MAKE) $(MFLAGS) clean
-	cd ..\leim
+	cd ..\..\leim
 	$(MAKE) $(MFLAGS) clean
 	cd ..\doc\emacs
 	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\misc
+	cd ..\misc
 	$(MAKE) $(MFLAGS) clean
-	cd ..\nt
+	cd ..\..\nt
 
 clean-other-dirs-gmake:
 	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean
@@ -381,13 +381,13 @@ distclean-other-dirs-nmake:
 	$(MAKE) $(MFLAGS) distclean
 	cd ..\doc\emacs
 	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\misc
+	cd ..\misc
 	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\lispintro
+	cd ..\lispintro
 	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\lispref
+	cd ..\lispref
 	$(MAKE) $(MFLAGS) distclean
-	cd ..\nt
+	cd ..\..\nt
 
 distclean-other-dirs-gmake:
 	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib distclean
@@ -415,13 +415,13 @@ maintainer-clean-other-dirs-nmake:
 	$(MAKE) $(MFLAGS) maintainer-clean
 	cd ..\doc\emacs
 	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\misc
+	cd ..\misc
 	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\lispintro
+	cd ..\lispintro
 	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\lispref
+	cd ..\lispref
 	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\nt
+	cd ..\..\nt
 
 maintainer-clean-other-dirs-gmake:
 	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib maintainer-clean

=== modified file 'nt/nmake.defs'
--- nt/nmake.defs	2011-05-07 04:00:12 +0000
+++ nt/nmake.defs	2011-11-05 09:51:52 +0000
@@ -109,7 +109,15 @@ RC		= rc
 RC_OUT		= -Fo
 RC_INCLUDE	= -i
 
-libc		= libc.lib
+USE_CRT_DLL	= 1
+
+!ifdef USE_CRT_DLL
+libc		= msvcrt$(D).lib
+EMACS_EXTRA_C_FLAGS= -D_DLL -D_MT -DUSE_CRT_DLL=1
+!else
+libc		= libcmt$(D).lib
+EMACS_EXTRA_C_FLAGS= -D_MT
+!endif
 baselibs	=
 O		= obj
 A		= lib
@@ -146,9 +154,13 @@ CFLAGS          = -I. $(ARCH_CFLAGS) \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(USER_CFLAGS) $(LOCAL_FLAGS)
 ESC_CFLAGS      = -I. $(ARCH_CFLAGS) \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(ESC_USER_CFLAGS) $(LOCAL_FLAGS)
-EMACS_EXTRA_C_FLAGS =
 
-SYS_LDFLAGS	= -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
+#SYS_LDFLAGS	= -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
+!ifdef NOOPT
+SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -debug -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
+!else
+SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
+!endif
 
 # see comments in allocate_heap in w32heap.c before changing any of the
 # -stack, -heap, or -base settings.
@@ -184,16 +196,20 @@ DEL_TREE	= rm -r
 !ifdef NODEBUG
 DEBUG_FLAG =
 DEBUG_LINK =
+D =
 !else
 DEBUG_FLAG = -Zi
-DEBUG_LINK = -debug:full
+DEBUG_LINK = -debug
+D = d
 !endif
 
 !if "$(ARCH)" == "i386"
 !ifdef NOOPT
-ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd $(DEBUG_FLAG)
 !else
-ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Oi -Ot -Oy- -Ob2 -GF -Gy -Gd $(DEBUG_FLAG)
 !endif
 ARCH_LDFLAGS	= $(SYS_LDFLAGS)
 


=== modified file 'src/lisp.h'
--- src/lisp.h	2011-10-28 13:48:19 +0000
+++ src/lisp.h	2011-11-05 10:16:18 +0000
@@ -168,6 +168,9 @@ extern int suppress_checking EXTERNALLY_
 #  if HAVE_ATTRIBUTE_ALIGNED
 #   define DECL_ALIGN(type, var) \
      type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var
+#  elif defined(_MSC_VER)
+#   define DECL_ALIGN(type, var) \
+     type __declspec(align(1 << GCTYPEBITS)) var
 #  else
      /* What directives do other compilers use?  */
 #  endif
@@ -225,6 +228,15 @@ extern int suppress_checking EXTERNALLY_
 # endif
 #endif
 
+/* Stolen from GDB.  The only known compiler that doesn't support
+   enums in bitfields is MSVC.  */
+#ifdef _MSC_VER
+#define ENUM_BF(TYPE) unsigned int
+#else
+#define ENUM_BF(TYPE) enum TYPE
+#endif
+
+
 enum Lisp_Type
   {
     /* Integer.  XINT (obj) is the integer value.  */
@@ -315,12 +327,12 @@ union Lisp_Object
 	/* Use explict signed, the signedness of a bit-field of type
 	   int is implementation defined.  */
 	signed EMACS_INT val  : VALBITS;
-	enum Lisp_Type type : GCTYPEBITS;
+	ENUM_BF (Lisp_Type) type : GCTYPEBITS;
       } s;
     struct
       {
 	EMACS_UINT val : VALBITS;
-	enum Lisp_Type type : GCTYPEBITS;
+	ENUM_BF (Lisp_Type) type : GCTYPEBITS;
       } u;
   }
 Lisp_Object;
@@ -336,14 +348,14 @@ union Lisp_Object
 
     struct
       {
-	enum Lisp_Type type : GCTYPEBITS;
+	ENUM_BF (Lisp_Type) type : GCTYPEBITS;
 	/* Use explict signed, the signedness of a bit-field of type
 	   int is implementation defined.  */
 	signed EMACS_INT val  : VALBITS;
       } s;
     struct
       {
-	enum Lisp_Type type : GCTYPEBITS;
+	ENUM_BF (Lisp_Type) type : GCTYPEBITS;
 	EMACS_UINT val : VALBITS;
       } u;
   }
@@ -1096,7 +1108,7 @@ struct Lisp_Symbol
      1 : it's a varalias, the value is really in the `alias' symbol.
      2 : it's a localized var, the value is in the `blv' object.
      3 : it's a forwarding variable, the value is in `forward'.  */
-  enum symbol_redirect redirect : 3;
+  ENUM_BF (symbol_redirect) redirect : 3;
 
   /* Non-zero means symbol is constant, i.e. changing its value
      should signal an error.  If the value is 3, then the var
@@ -1309,7 +1321,7 @@ struct Lisp_Hash_Table
 
 struct Lisp_Misc_Any		/* Supertype of all Misc types.  */
 {
-  enum Lisp_Misc_Type type : 16;		/* = Lisp_Misc_??? */
+  ENUM_BF (Lisp_Misc_Type) type : 16;		/* = Lisp_Misc_??? */
   unsigned gcmarkbit : 1;
   int spacer : 15;
   /* Make it as long as "Lisp_Free without padding".  */
@@ -1318,7 +1330,7 @@ struct Lisp_Misc_Any		/* Supertype of al
 
 struct Lisp_Marker
 {
-  enum Lisp_Misc_Type type : 16;		/* = Lisp_Misc_Marker */
+  ENUM_BF (Lisp_Misc_Type) type : 16;		/* = Lisp_Misc_Marker */
   unsigned gcmarkbit : 1;
   int spacer : 13;
   /* This flag is temporarily used in the functions
@@ -1468,7 +1480,7 @@ struct Lisp_Overlay
    I.e. 9words plus 2 bits, 3words of which are for external linked lists.
 */
   {
-    enum Lisp_Misc_Type type : 16;	/* = Lisp_Misc_Overlay */
+    ENUM_BF (Lisp_Misc_Type) type : 16;	/* = Lisp_Misc_Overlay */
     unsigned gcmarkbit : 1;
     int spacer : 15;
     struct Lisp_Overlay *next;
@@ -1487,7 +1499,7 @@ struct Lisp_Kboard_Objfwd
    This type of object is used in the arg to record_unwind_protect.  */
 struct Lisp_Save_Value
   {
-    enum Lisp_Misc_Type type : 16;	/* = Lisp_Misc_Save_Value */
+    ENUM_BF (Lisp_Misc_Type) type : 16;	/* = Lisp_Misc_Save_Value */
     unsigned gcmarkbit : 1;
     int spacer : 14;
     /* If DOGC is set, POINTER is the address of a memory
@@ -1501,7 +1513,7 @@ struct Lisp_Save_Value
 /* A miscellaneous object, when it's on the free list.  */
 struct Lisp_Free
   {
-    enum Lisp_Misc_Type type : 16;	/* = Lisp_Misc_Free */
+    ENUM_BF (Lisp_Misc_Type) type : 16;	/* = Lisp_Misc_Free */
     unsigned gcmarkbit : 1;
     int spacer : 15;
     union Lisp_Misc *chain;
@@ -1896,13 +1908,23 @@ typedef struct {
 
 /* This version of DEFUN declares a function prototype with the right
    arguments, so we can catch errors with maxargs at compile-time.  */
-#define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc) \
-  Lisp_Object fnname DEFUN_ARGS_ ## maxargs ;				\
-  static DECL_ALIGN (struct Lisp_Subr, sname) =				\
-    { PVEC_SUBR,							\
-      { .a ## maxargs = fnname },				\
-      minargs, maxargs, lname, intspec, 0};				\
-  Lisp_Object fnname
+#ifdef _MSC_VER
+#define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)	\
+   Lisp_Object fnname DEFUN_ARGS_ ## maxargs ;				\
+   static DECL_ALIGN (struct Lisp_Subr, sname) =			\
+     { PVEC_SUBR | (sizeof (struct Lisp_Subr) / sizeof (EMACS_INT)),	\
+      { (Lisp_Object (__cdecl *)(void))fnname },                        \
+       minargs, maxargs, lname, intspec, 0};				\
+   Lisp_Object fnname
+#else  /* not _MSC_VER */
+#define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)	\
+   Lisp_Object fnname DEFUN_ARGS_ ## maxargs ;				\
+   static DECL_ALIGN (struct Lisp_Subr, sname) =			\
+     { PVEC_SUBR,							\
+      { .a ## maxargs = fnname },					\
+       minargs, maxargs, lname, intspec, 0};				\
+   Lisp_Object fnname
+#endif
 
 /* Note that the weird token-substitution semantics of ANSI C makes
    this work for MANY and UNEVALLED.  */

=== modified file 'src/makefile.w32-in'
--- src/makefile.w32-in	2011-08-27 01:42:00 +0000
+++ src/makefile.w32-in	2011-11-05 08:55:15 +0000
@@ -348,11 +348,11 @@ TAGS-LISP: $(OBJ0) $(OBJ1) $(OBJ2)
 TAGS-gmake:
 	../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \
 	  --regex=@../nt/emacs-src.tags \
-	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
+	  $(OBJ0_c)
 	../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
-	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
+	  $(OBJ1_c)
 	../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \
-	  $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
+	  $(OBJ2_c) \
 	  $(CURDIR)/*.h $(CURDIR)/m/intel386.h $(CURDIR)/s/ms-w32.h
 
 TAGS-nmake:

=== modified file 'src/regex.c'
--- src/regex.c	2011-09-09 01:06:52 +0000
+++ src/regex.c	2011-11-05 08:47:01 +0000
@@ -530,7 +530,11 @@ init_syntax_once (void)
 #define MIN(a, b) ((a) < (b) ? (a) : (b))
 
 /* Type of source-pattern and string chars.  */
+#ifdef _MSC_VER
+typedef unsigned char re_char;
+#else
 typedef const unsigned char re_char;
+#endif
 
 typedef char boolean;
 #define false 0

=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h	2011-07-07 01:32:56 +0000
+++ src/s/ms-w32.h	2011-11-05 09:21:05 +0000
@@ -86,6 +86,12 @@ along with GNU Emacs.  If not, see <http
 #define IS_ANY_SEP(_c_) (IS_DIRECTORY_SEP (_c_) || IS_DEVICE_SEP (_c_))
 
 #include <sys/types.h>
+
+#ifdef _MSC_VER
+typedef unsigned long sigset_t;
+typedef int ssize_t;
+#endif
+
 struct sigaction {
   int sa_flags;
   void (*sa_handler)(int);
@@ -181,6 +187,12 @@ struct sigaction {
 
 #ifdef emacs
 
+#ifdef _MSC_VER
+#include <sys/timeb.h>
+#include <sys/stat.h>
+#include <signal.h>
+#endif
+
 /* Calls that are emulated or shadowed.  */
 #undef access
 #define access  sys_access
@@ -270,6 +282,15 @@ typedef int pid_t;
 #define utime	  _utime
 #endif
 
+#ifdef _MSC_VER
+/* MSVC gets link-time errors without these redirections.  */
+#define fstat(a, b) sys_fstat(a, b)
+#define stat(a, b)  sys_stat(a, b)
+#if _MSC_VER >= 1400
+#define utime       sys_utime
+#endif
+#endif
+
 /* This is hacky, but is necessary to avoid warnings about macro
    redefinitions using the SDK compilers.  */
 #ifndef __STDC__
@@ -317,13 +338,17 @@ extern char *get_emacs_configuration_opt
 #define _WINSOCK_H
 
 /* Defines size_t and alloca ().  */
-#ifdef USE_CRT_DLL
+#if (defined(_MSC_VER) && defined(emacs)) || defined(USE_CRT_DLL)
 #define malloc e_malloc
 #define free   e_free
 #define realloc e_realloc
 #define calloc e_calloc
 #endif
+#ifdef _MSC_VER
+#define alloca _alloca
+#else
 #include <malloc.h>
+#endif
 
 #include <sys/stat.h>
 

=== modified file 'src/w32.c'
--- src/w32.c	2011-10-27 00:59:21 +0000
+++ src/w32.c	2011-11-05 09:18:42 +0000
@@ -94,7 +94,9 @@ typedef struct _MEMORY_STATUS_EX {
 
 #include <tlhelp32.h>
 #include <psapi.h>
+#ifndef _MSC_VER
 #include <w32api.h>
+#endif
 #if !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
@@ -1547,7 +1549,12 @@ init_environment (char ** argv)
 	 read-only filesystem, like CD-ROM or a write-protected floppy.
 	 The only way to be really sure is to actually create a file and
 	 see if it succeeds.  But I think that's too much to ask.  */
+#ifdef _MSC_VER
+      /* MSVC's _access crashes with D_OK.  */
+      if (tmp && sys_access (tmp, D_OK) == 0)
+#else
       if (tmp && _access (tmp, D_OK) == 0)
+#endif
 	{
 	  char * var = alloca (strlen (tmp) + 8);
 	  sprintf (var, "TMPDIR=%s", tmp);

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2011-11-03 19:04:18 +0000
+++ src/w32fns.c	2011-11-05 09:19:45 +0000
@@ -140,8 +140,8 @@ struct MONITOR_INFO
     DWORD   dwFlags;
 };
 
-/* Reportedly, VS 6 does not have this in its headers.  */
-#if defined (_MSC_VER) && _MSC_VER < 1300
+/* Reportedly, MSVC does not have this in its headers.  */
+#ifdef _MSC_VER
 DECLARE_HANDLE(HMONITOR);
 #endif
 

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 13:19:28 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9960@debbugs.gnu.org
> 
> What follows is discussion of some of the changes suggested by
> Fabrice, including the description of how they were adapted to the
> current trunk, and the diffs that will be actually committed shortly.

Committed as revision 106292 on the trunk.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/5/2011 5:39 AM, Eli Zaretskii wrote:
>> Date: Sat, 05 Nov 2011 13:19:28 +0200
>> From: Eli Zaretskii<eliz@gnu.org>
>> Cc: 9960@debbugs.gnu.org
>>
>> What follows is discussion of some of the changes suggested by
>> Fabrice, including the description of how they were adapted to the
>> current trunk, and the diffs that will be actually committed shortly.
>
> Committed as revision 106292 on the trunk.

I tried building with Visual Studio 2008 (Express Edition) and the build 
fails:

         cl -I. -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd -Zi 
-DEMACSDEBUG -DENA
BLE_CHECKING -DXASSERTS -I"D:/devel/emacs/libs/libXpm-3.5.8/include" 
-I"D:/devel
/emacs/libs/libXpm-3.5.8/src" 
-I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
  -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" 
-I"D:/devel/emacs/libs/giflib-
4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" 
-I"D:/devel/emacs/lib
s/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" 
-DHAVE_CON
FIG_H=1 -I. -I../nt/inc -I../src -Foobj/i386\ md5.c sha1.c sha256.c 
sha512.c fil
emode.c
md5.c
md5.c(259) : warning C4116: unnamed type definition in parentheses
sha1.c
sha1.c(74) : error C2054: expected '(' to follow 'inline'
sha1.c(75) : error C2085: 'set_uint32' : not in formal parameter list
sha1.c(75) : error C2143: syntax error : missing ';' before '{'
sha1.c(246) : warning C4116: unnamed type definition in parentheses
sha256.c
sha256.c(93) : error C2054: expected '(' to follow 'inline'
sha256.c(94) : error C2085: 'set_uint32' : not in formal parameter list
sha256.c(94) : error C2143: syntax error : missing ';' before '{'
sha256.c(378) : warning C4116: unnamed type definition in parentheses

[...] (more errors after this)

This is caused by `inline' keyword, which should be `__inline' for MSVC. 
I don't see any place where this would be defined for the W32 build. Am 
I missing something?

Christoph

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 06:54:39 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org
> 
> I tried building with Visual Studio 2008 (Express Edition) and the build 
> fails:
> 
>          cl -I. -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd -Zi 
> -DEMACSDEBUG -DENA
> BLE_CHECKING -DXASSERTS -I"D:/devel/emacs/libs/libXpm-3.5.8/include" 
> -I"D:/devel
> /emacs/libs/libXpm-3.5.8/src" 
> -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
>   -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" 
> -I"D:/devel/emacs/libs/giflib-
> 4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" 
> -I"D:/devel/emacs/lib
> s/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" 
> -DHAVE_CON
> FIG_H=1 -I. -I../nt/inc -I../src -Foobj/i386\ md5.c sha1.c sha256.c 
> sha512.c fil
> emode.c
> md5.c
> md5.c(259) : warning C4116: unnamed type definition in parentheses
> sha1.c
> sha1.c(74) : error C2054: expected '(' to follow 'inline'
> sha1.c(75) : error C2085: 'set_uint32' : not in formal parameter list
> sha1.c(75) : error C2143: syntax error : missing ';' before '{'
> sha1.c(246) : warning C4116: unnamed type definition in parentheses
> sha256.c
> sha256.c(93) : error C2054: expected '(' to follow 'inline'
> sha256.c(94) : error C2085: 'set_uint32' : not in formal parameter list
> sha256.c(94) : error C2143: syntax error : missing ';' before '{'
> sha256.c(378) : warning C4116: unnamed type definition in parentheses
> 
> [...] (more errors after this)
> 
> This is caused by `inline' keyword, which should be `__inline' for MSVC. 
> I don't see any place where this would be defined for the W32 build. Am 
> I missing something?

Does this patch give good results?

=== modified file 'nt/config.nt'
--- nt/config.nt	2011-10-31 02:25:01 +0000
+++ nt/config.nt	2011-11-05 13:21:58 +0000
@@ -328,9 +328,13 @@ along with GNU Emacs.  If not, see <http
 
 /* Define to `__inline__' or `__inline' if that's what the C compiler
    calls it, or to nothing if 'inline' is not supported under any name.  */
+#ifdef __GNUC__
 #ifndef __cplusplus
 #undef inline
 #endif
+#else  /* MSVC */
+#define inline __inline
+#endif
 
 /* Define to the equivalent of the C99 'restrict' keyword, or to
    nothing if this is not supported.  Do not define if restrict is

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/5/2011 7:22 AM, Eli Zaretskii wrote:

> Does this patch give good results?

Yes. Better. Thanks.

Then it can't find a definition of `mode_t' in `strmode'.

This patch will fix this error:

  /* Define to the equivalent of the C99 'restrict' keyword, or to
     nothing if this is not supported.  Do not define if restrict is
@@ -341,6 +345,13 @@
  # define restrict
  #endif

+/* Define to `int' if <sys/types.h> does not define. */
+#ifdef __GNUC__
+/* No action required for gcc */
+#else /* MSVC */
+#define mode_t int
+#endif
+
  /* A va_copy replacement for MSVC.  */
  #ifdef _MSC_VER
  # ifdef _WIN64


After that, I get a link error for ctags:

ctags.obj : error LNK2019: unresolved external symbol _sys_stat 
referenced in fu
nction _process_file_name
obj/i386/ctags.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\
VC\BIN\link.EXE"' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\
VC\BIN\nmake.exe"' : return code '0x2'
Stop.

I am not sure what to do about _sys_stat.

Christoph

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 07:58:12 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org
> 
> On 11/5/2011 7:22 AM, Eli Zaretskii wrote:
> 
> > Does this patch give good results?
> 
> Yes. Better. Thanks.

Committed.

> Then it can't find a definition of `mode_t' in `strmode'.
> 
> This patch will fix this error:
> 
>   /* Define to the equivalent of the C99 'restrict' keyword, or to
>      nothing if this is not supported.  Do not define if restrict is
> @@ -341,6 +345,13 @@
>   # define restrict
>   #endif
> 
> +/* Define to `int' if <sys/types.h> does not define. */
> +#ifdef __GNUC__
> +/* No action required for gcc */
> +#else /* MSVC */
> +#define mode_t int
> +#endif
> +
>   /* A va_copy replacement for MSVC.  */
>   #ifdef _MSC_VER
>   # ifdef _WIN64

Please commit this, thanks.

> After that, I get a link error for ctags:
> 
> ctags.obj : error LNK2019: unresolved external symbol _sys_stat 
> referenced in fu
> nction _process_file_name
> obj/i386/ctags.exe : fatal error LNK1120: 1 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 9.0\
> VC\BIN\link.EXE"' : return code '0x460'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 9.0\
> VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> 
> I am not sure what to do about _sys_stat.

Try this one:

=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h	2011-11-05 11:34:56 +0000
+++ src/s/ms-w32.h	2011-11-05 14:15:45 +0000
@@ -191,6 +191,11 @@ struct sigaction {
 #include <sys/timeb.h>
 #include <sys/stat.h>
 #include <signal.h>
+
+/* MSVC gets link-time errors without these redirections.  */
+#define fstat(a, b) sys_fstat(a, b)
+#define stat(a, b)  sys_stat(a, b)
+#define utime       sys_utime
 #endif
 
 /* Calls that are emulated or shadowed.  */
@@ -279,18 +284,10 @@ typedef int pid_t;
 
 #if !defined (_MSC_VER) || (_MSC_VER < 1400)
 #define tzname    _tzname
+#undef  utime
 #define utime	  _utime
 #endif
 
-#ifdef _MSC_VER
-/* MSVC gets link-time errors without these redirections.  */
-#define fstat(a, b) sys_fstat(a, b)
-#define stat(a, b)  sys_stat(a, b)
-#if _MSC_VER >= 1400
-#define utime       sys_utime
-#endif
-#endif
-
 /* This is hacky, but is necessary to avoid warnings about macro
    redefinitions using the SDK compilers.  */
 #ifndef __STDC__

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 16:16:40 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org
> 
> > +/* Define to `int' if <sys/types.h> does not define. */
> > +#ifdef __GNUC__
> > +/* No action required for gcc */
> > +#else /* MSVC */
> > +#define mode_t int
> > +#endif
> > +
> >   /* A va_copy replacement for MSVC.  */
> >   #ifdef _MSC_VER
> >   # ifdef _WIN64
> 
> Please commit this, thanks.

Actually, it's better to say

 #ifdef _MSC_VER
 typedef unsigned short mode_t;
 #endif

since that is how MS headers define it in their sys/stat.h.

bug#9960: Compiling Emacs trunk with MSVC

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, it's better to say
>
>  #ifdef _MSC_VER
>  typedef unsigned short mode_t;
>  #endif
>
> since that is how MS headers define it in their sys/stat.h.

Why not

  #ifdef _MSC_VER
  #include "sys/stat.h"
  #endif

?

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: cschol2112@googlemail.com,  fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 16:51:55 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Actually, it's better to say
> >
> >  #ifdef _MSC_VER
> >  typedef unsigned short mode_t;
> >  #endif
> >
> > since that is how MS headers define it in their sys/stat.h.
> 
> Why not
> 
>   #ifdef _MSC_VER
>   #include "sys/stat.h"
>   #endif
> 
> ?

Because at least some versions of Microsoft's stat.h don't define
mode_t, but instead use "unsigned short" literally in `struct stat'
definition.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

> Please commit this, thanks.

Done.

> Try this one:

This works.

Next problem:

emacsclient.obj : error LNK2001: unresolved external symbol __environ
obj/i386/emacsclient.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
VC\BIN\link.EXE"' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
VC\BIN\nmake.exe"' : return code '0x2'
Stop.

A similar problem is described here
http://comments.gmane.org/gmane.comp.emulators.wine.devel/84654, but
removing our extern declaration does not fix the problem as it did for them.

Also, `environ' has been deprecated since VS2005, see
http://msdn.microsoft.com/en-us/library/stxk41x1%28v=VS.90%29.aspx, but
that does not have to be resolved now.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 10:27:50 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please commit this, thanks.
> 
> Done.

Thank, but see my followup, with a better (and more correct) variant.

> Next problem:
> 
> emacsclient.obj : error LNK2001: unresolved external symbol __environ
> obj/i386/emacsclient.exe : fatal error LNK1120: 1 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
> VC\BIN\link.EXE"' : return code '0x460'
> Stop.

No idea about this one.  Seems to be the consequence of using -D_MT in
the compiler flags, but that was suggested by Fabrice, and I really
don't know why is that important, or even what does it do, exactly.
Does it work if you remove -D_MT from EMACS_EXTRA_C_FLAGS in
nt/nmake.defs?

Anyway, can you work around this somehow and get to compiling Emacs
itself?  That's the important thing here, not lib-src programs, with
all due respect I have to them.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 18:50:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org
> 
> > emacsclient.obj : error LNK2001: unresolved external symbol __environ
> > obj/i386/emacsclient.exe : fatal error LNK1120: 1 unresolved externals
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
> > VC\BIN\link.EXE"' : return code '0x460'
> > Stop.
> 
> No idea about this one.

Btw, if you mean this one:

  /* Send over our environment and current directory. */
  if (!current_frame)
    {
      extern char **environ;
      int i;
      for (i = 0; environ[i]; i++)
        {
          send_to_emacs (emacs_socket, "-env ");
          quote_argument (emacs_socket, environ[i]);
          send_to_emacs (emacs_socket, " ");
        }

then it was there since 2005, so Fabrice's build somehow succeeded to
get past it.  Some factor other than the declaration is at work here.
Maybe I goofed in my changes in nmake.defs.  Hopefully, someone or
Fabrice himself will figure this out.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

> Thank, but see my followup, with a better (and more correct) variant.

OK. I fixed it. Thanks.

> No idea about this one.  Seems to be the consequence of using -D_MT in
> the compiler flags, but that was suggested by Fabrice, and I really
> don't know why is that important, or even what does it do, exactly.
> Does it work if you remove -D_MT from EMACS_EXTRA_C_FLAGS in
> nt/nmake.defs?

No. The error remains after removing -D_MT.

> Anyway, can you work around this somehow and get to compiling Emacs
> itself?  That's the important thing here, not lib-src programs, with
> all due respect I have to them.

I will try. I might just have to remove the lib-src stuff from the make
process.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> I will try. I might just have to remove the lib-src stuff from the make
> process.

OK. So I removed emacsclient from the build process and we can move on.

Next error:

nmake does not like the relative path invocation of make-docfile with
forward slashes (makefile.w32-in, l.235)

"../lib-src/$(BLD)/make-docfile" -d . -g $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp

If I hardcode this to 

"..\\lib-src\\obj\\i386\\make-docfile" -d . -g $(SOME_MACHINE_OBJECTS)
$(obj) > gl-tmp

it works. We might have to use forward slashes here and change BLD accordingly?

Then we get to emacs.c:

d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2061: syntax er
ror : identifier 'cons_to_signed'
d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er
ror : ';'
d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er
ror : 'type'
emacs.c(537) : error C2059: syntax error : '<<'
emacs.c(537) : error C2059: syntax error : 'constant'
emacs.c(537) : error C2059: syntax error : ')'
emacs.c(545) : error C2059: syntax error : '<<'
emacs.c(545) : error C2059: syntax error : 'constant'
emacs.c(545) : error C2059: syntax error : ')'
emacs.c(1992) : error C2059: syntax error : '<<'
emacs.c(1992) : error C2059: syntax error : 'constant'
emacs.c(1992) : error C2059: syntax error : ')'
emacs.c(2130) : error C2059: syntax error : '<<'
emacs.c(2130) : error C2059: syntax error : 'constant'
emacs.c(2130) : error C2059: syntax error : ')'
emacs.c(2337) : error C2059: syntax error : '<<'
emacs.c(2337) : error C2059: syntax error : 'constant'
emacs.c(2337) : error C2059: syntax error : ')'
emacs.c(2352) : error C2059: syntax error : '<<'
emacs.c(2352) : error C2059: syntax error : 'constant'
emacs.c(2352) : error C2059: syntax error : ')'


I am starting to wonder how Fabrice ever got this to compile. Are all of
these errors due to changes made between his original patch and the
current trunk state?

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 12:20:22 -0600
> 
> nmake does not like the relative path invocation of make-docfile with
> forward slashes (makefile.w32-in, l.235)
> 
> "../lib-src/$(BLD)/make-docfile" -d . -g $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp

Why?? even cmd.exe is in peace with forward slashes, as long as they
are in quotes.  What is the error message? are you sure the problem is
with forward slashes, and not with something else?  If the problem is
with forward slashes, how come invocations of make-docfile and other
commands in lib-src/makefile.w32-in, which also use forward slashes,
did work?

Are you sure you are using nmake that came with the version of Studio
that you are using to compile, and not some ancient version?

> If I hardcode this to 
> 
> "..\\lib-src\\obj\\i386\\make-docfile" -d . -g $(SOME_MACHINE_OBJECTS)
> $(obj) > gl-tmp
> 
> it works. We might have to use forward slashes here and change BLD accordingly?

That way lies madness.  This worked with nmake for ages.  We cannot
possibly change all slashes in all the makefile's, I don't even know
any portable method of doing that, without breaking builds with a
Unixy shell, which we also support.

We must to get to the bottom of this problem.

> d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2061: syntax er
> ror : identifier 'cons_to_signed'
> d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er
> ror : ';'
> d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er
> ror : 'type'

Is the problem with Lisp_Object or with intmax_t?  (You can find out
if you change each one to some standard type, like `int'.)

> emacs.c(537) : error C2059: syntax error : '<<'
> emacs.c(537) : error C2059: syntax error : 'constant'
> emacs.c(537) : error C2059: syntax error : ')'
> emacs.c(545) : error C2059: syntax error : '<<'
> emacs.c(545) : error C2059: syntax error : 'constant'
> emacs.c(545) : error C2059: syntax error : ')'
> emacs.c(1992) : error C2059: syntax error : '<<'
> emacs.c(1992) : error C2059: syntax error : 'constant'
> emacs.c(1992) : error C2059: syntax error : ')'
> emacs.c(2130) : error C2059: syntax error : '<<'
> emacs.c(2130) : error C2059: syntax error : 'constant'
> emacs.c(2130) : error C2059: syntax error : ')'
> emacs.c(2337) : error C2059: syntax error : '<<'
> emacs.c(2337) : error C2059: syntax error : 'constant'
> emacs.c(2337) : error C2059: syntax error : ')'
> emacs.c(2352) : error C2059: syntax error : '<<'
> emacs.c(2352) : error C2059: syntax error : 'constant'
> emacs.c(2352) : error C2059: syntax error : ')'

These all are about DEFUN.  The only thing I changed in the definition
provided by Fabrice was to add "static" here:

  +#define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)    \
  +   Lisp_Object fnname DEFUN_ARGS_ ## maxargs ;                         \
  +   static DECL_ALIGN (struct Lisp_Subr, sname) =                       \
      ^^^^^^
Please remove the "static" part and see if that helps.

> I am starting to wonder how Fabrice ever got this to compile. Are all of
> these errors due to changes made between his original patch and the
> current trunk state?

Yes.  You now have an idea how many water goes under the bridge in one
year of Emacs development.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> Then we get to emacs.c:
> emacs.c(537) : error C2059: syntax error : '<<'
> emacs.c(537) : error C2059: syntax error : 'constant'
> emacs.c(537) : error C2059: syntax error : ')'

cl.exe does not like the shift operator in this statement:

static int __declspec(align(1 << 3)) test = 1;

whereas 

static int __declspec(align(8)) test = 1;

works. 

The above is a simple test case to confirm the fault is in this
code in lisp.h, l.172:

#  elif defined(_MSC_VER)
#   define DECL_ALIGN(type, var) \
     type __declspec(align(1 << GCTYPEBITS)) var


Other errors are due to missing definitions in stdint.h. The following
patch fixes this (64bit support added for completeness):

=== modified file 'nt/inc/stdint.h'
--- nt/inc/stdint.h	2011-06-07 12:34:09 +0000
+++ nt/inc/stdint.h	2011-11-05 20:03:50 +0000
@@ -27,21 +27,37 @@
 /* Minimum definitions to allow compilation with tool chains where
    stdint.h is not available, e.g. Microsoft Visual Studio.  */
 
-typedef unsigned int uint32_t;
-#define INT32_MAX 2147483647
-/* "i64" is the non-standard suffix used by MSVC for 64-bit constants.  */
-#define INT64_MAX 9223372036854775807i64
-
 #ifdef _WIN64
   typedef __int64 intptr_t;
+#define UINT64_MAX 18446744073709551616
+#define UINT64_MIN 0
+/* "i64" is the non-standard suffix used by MSVC for 64-bit constants.  */
+#define INT64_MAX 9223372036854775807i64
+#define INT64_MIN (~INT64_MAX)
 #define INTPTR_MAX INT64_MAX
+#define UINTMAX_MAX UINT64_MAX
+#define UINTMAX_MIN UINT64_MIN
+#define INTMAX_MAX INT64_MAX
+#define INTMAX_MIN INT64_MIN
 #else
   typedef int intptr_t;
+typedef unsigned int uint32_t;
+#define UINT32_MAX 4294967296
+#define UINT32_MIN 0
+#define INT32_MAX 2147483647
+#define INT32_MIN (~INT32_MAX)
 #define INTPTR_MAX INT32_MAX
+#define UINTMAX_MAX UINT32_MAX
+#define UINTMAX_MIN UINT32_MIN
+#define INTMAX_MAX INT32_MAX
+#define INTMAX_MIN INT32_MIN
 #endif
 
 #define uintmax_t unsigned __int64
+#define intmax_t __int64
 #define PTRDIFF_MAX INTPTR_MAX
+
+
 
 #endif	/* !__GNUC__ */


There are tons of warnings, but everything compiles from then
on. 

Creating temacs.lib fails when linking with the following errors:

temacs2.lib(font.obj) : error LNK2019: unresolved external symbol _snprintf refe
renced in function _font_unparse_xlfd
temacs2.lib(fringe.obj) : error LNK2019: unresolved external symbol _window_box_
right referenced in function _draw_fringe_bitmap_1
temacs2.lib(w32term.obj) : error LNK2001: unresolved external symbol _window_box
_right
temacs2.lib(xdisp.obj) : error LNK2019: unresolved external symbol _strtoimax re
ferenced in function _message_log_check_duplicate
libgnu.lib(strftime.obj) : error LNK2001: unresolved external symbol _tzname
obj/i386/temacs.bin : fatal error LNK1120: 4 unresolved externals

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

> Why?? even cmd.exe is in peace with forward slashes, as long as they
> are in quotes.  What is the error message? are you sure the problem is
> with forward slashes, and not with something else?  If the problem is
> with forward slashes, how come invocations of make-docfile and other
> commands in lib-src/makefile.w32-in, which also use forward slashes,
> did work?

No idea. I will dig into this some more.

> Are you sure you are using nmake that came with the version of Studio
> that you are using to compile, and not some ancient version?

Yes. nmake from VS2008 Express, I checked.

> That way lies madness.  This worked with nmake for ages.  We cannot
> possibly change all slashes in all the makefile's, I don't even know
> any portable method of doing that, without breaking builds with a
> Unixy shell, which we also support.
>
> We must to get to the bottom of this problem.

I agree. It seems very strange.

> Is the problem with Lisp_Object or with intmax_t?  (You can find out
> if you change each one to some standard type, like `int'.)

intmax_t was missing, see my other email.

> Please remove the "static" part and see if that helps.

No. Did not help. See my other email for a potential source of problem.

> Yes.  You now have an idea how many water goes under the bridge in one
> year of Emacs development.

Just wow. ;)

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 14:38:41 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why?? even cmd.exe is in peace with forward slashes, as long as they
> > are in quotes.  What is the error message? are you sure the problem is
> > with forward slashes, and not with something else?  If the problem is
> > with forward slashes, how come invocations of make-docfile and other
> > commands in lib-src/makefile.w32-in, which also use forward slashes,
> > did work?
> 
> No idea. I will dig into this some more.

Thanks.  Could it be that the quotes are the problem?

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 14:32:15 -0600
> 
> Christoph Scholtes <cschol2112@googlemail.com> writes:
> 
> > Then we get to emacs.c:
> > emacs.c(537) : error C2059: syntax error : '<<'
> > emacs.c(537) : error C2059: syntax error : 'constant'
> > emacs.c(537) : error C2059: syntax error : ')'
> 
> cl.exe does not like the shift operator in this statement:
> 
> static int __declspec(align(1 << 3)) test = 1;

That comes from Fabrice, assuming that removing `static' doesn't help.

Does it fail even if you take (1 << 3) in one more level of
parentheses?

What about an intermediate macro, as in

 #define FOO (1 << GCTYPEBITS)
 static int __declspec(align(FOO)) test = 1;

?

> Other errors are due to missing definitions in stdint.h. The following
> patch fixes this (64bit support added for completeness):

Thanks, please install this.

> Creating temacs.lib fails when linking with the following errors:
> 
> temacs2.lib(font.obj) : error LNK2019: unresolved external symbol _snprintf referenced in function _font_unparse_xlfd

Does this go away if you add "#define snprintf _snprintf" to
src/s/ms-w32.h, for MSVC only?

> temacs2.lib(fringe.obj) : error LNK2019: unresolved external symbol _window_box_right referenced in function _draw_fringe_bitmap_1
> temacs2.lib(w32term.obj) : error LNK2001: unresolved external symbol _window_box_right

These are because xdisp.c defines window_box_right `inline'.  (This is
an optimized build, right? if not, does it mean that MSVC inlines
functions even for a non-optimized builds?)  I would suggest to make
that `inline' conditional on _MSC_VER being undefined.

> temacs2.lib(xdisp.obj) : error LNK2019: unresolved external symbol _strtoimax referenced in function _message_log_check_duplicate

Add "#define strtoimax _strtoi64" to src/s/ms-w32.h, conditioned on
_MSC_VER.

> libgnu.lib(strftime.obj) : error LNK2001: unresolved external symbol _tzname
> obj/i386/temacs.bin : fatal error LNK1120: 4 unresolved externals

Make this (from src/s/ms-w32.h):

  #if !defined (_MSC_VER) || (_MSC_VER < 1400)
  #define tzname    _tzname

be defined unconditionally.  (But leave the "utime" part under the
same condition it is today.)

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/5/2011 3:11 PM, Eli Zaretskii wrote:

> Thanks.  Could it be that the quotes are the problem?

No. I looked into other cases where this does not seem to be a problem 
and this seems solve it:

"$(THISDIR)/$(dot)$(dot)/lib-src/$(OBJ)/make-docfile" -d . -g 
$(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp

It actually didn't like the `..'.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/5/2011 4:07 PM, Christoph Scholtes wrote:
> On 11/5/2011 3:11 PM, Eli Zaretskii wrote:
>
>> Thanks. Could it be that the quotes are the problem?
>
> No. I looked into other cases where this does not seem to be a problem
> and this seems solve it:
>
> "$(THISDIR)/$(dot)$(dot)/lib-src/$(OBJ)/make-docfile" -d . -g
> $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp
>
> It actually didn't like the `..'.

Never mind this. Something wasn't right. This doesn't work at all...

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/5/2011 4:15 PM, Christoph Scholtes wrote:
> On 11/5/2011 4:07 PM, Christoph Scholtes wrote:
>> On 11/5/2011 3:11 PM, Eli Zaretskii wrote:
>>
>>> Thanks. Could it be that the quotes are the problem?
>>
>> No. I looked into other cases where this does not seem to be a problem
>> and this seems solve it:
>>
>> "$(THISDIR)/$(dot)$(dot)/lib-src/$(OBJ)/make-docfile" -d . -g
>> $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp
>>
>> It actually didn't like the `..'.
>
> Never mind this. Something wasn't right. This doesn't work at all...

"$(THISDIR)/../lib-src/$(BLD)/make-docfile" -d . -g 
$(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp

This works. Sorry.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Eli Zaretskii <eliz@gnu.org> writes:

> That comes from Fabrice, assuming that removing `static' doesn't help.

No, it does not.

> Does it fail even if you take (1 << 3) in one more level of
> parentheses?

Yes.

> What about an intermediate macro, as in
>
>  #define FOO (1 << GCTYPEBITS)
>  static int __declspec(align(FOO)) test = 1;
>
> ?

Not working. I tried all of these cases in my simple example. It does
seem to like the shift operator.

>> Other errors are due to missing definitions in stdint.h. The following
>> patch fixes this (64bit support added for completeness):
>
> Thanks, please install this.

I will. Thanks.

> Does this go away if you add "#define snprintf _snprintf" to
> src/s/ms-w32.h, for MSVC only?

Yes.

> These are because xdisp.c defines window_box_right `inline'.  (This is
> an optimized build, right? if not, does it mean that MSVC inlines
> functions even for a non-optimized builds?)  I would suggest to make
> that `inline' conditional on _MSC_VER being undefined.

That worked.

> Add "#define strtoimax _strtoi64" to src/s/ms-w32.h, conditioned on
> _MSC_VER.

Worked.

> Make this (from src/s/ms-w32.h):
>
>   #if !defined (_MSC_VER) || (_MSC_VER < 1400)
>   #define tzname    _tzname
>
> be defined unconditionally.  (But leave the "utime" part under the
> same condition it is today.)

This is a problem. The ensuing error is:

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\time.h(281) : erro
r C2090: function returns array

From time.h:
_CRT_INSECURE_DEPRECATE_GLOBALS(_get_tzname) _CRTIMP extern char * tzname[2];

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

Ouch. I'm not up to speed to answer all of this.
(Spent the day in a plane to go to some conference near Miami).
I should be able to check with my copy in a couple of days.

One thing you need to pay attention too is : are you linking with LIBC or
MSVCRT ?
I used to link with MSVCRT (MS would like to get rid of LIBC).

Best regards,

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Christoph Scholtes <cschol2112@googlemail.com> writes:

>> Make this (from src/s/ms-w32.h):
>>
>>   #if !defined (_MSC_VER) || (_MSC_VER < 1400)
>>   #define tzname    _tzname
>>
>> be defined unconditionally.  (But leave the "utime" part under the
>> same condition it is today.)
>
> This is a problem. The ensuing error is:
>
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\time.h(281) : erro
> r C2090: function returns array
>
> From time.h:
> _CRT_INSECURE_DEPRECATE_GLOBALS(_get_tzname) _CRTIMP extern char * tzname[2];

I found this old thread dealing with MSVC problems:
http://old.nabble.com/Compilation-problems-with-latest-MSVC-td8040440.html

I undef'ed HAVE_TZNAME and it linked, but then crashed when dumping with
the following error:

Dumping from obj/i386/temacs.bin
          to obj/i386/temacs.exe
        "D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/temacs.exe" -batch
-l loadup dump
NMAKE : fatal error U1077: 'D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/
temacs.exe' : return code '0xc0000135'
Stop.

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> Ouch. I'm not up to speed to answer all of this.(Spent the day in a
> plane to go to some conference near Miami).

Sorry, I had a lot of time to spend on this today. ;)

> I should be able to check with my copy in a couple of days.One thing
> you need to pay attention too is : are you linking with LIBC or MSVCRT
> ?

That would be great. I am pretty sure I am. nmake.defs defines `_MT' and
`_DLL', which according to the documentation
(http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=VS.90%29.aspx)
cause the compiler to link against MSCVRT.lib.

Christoph

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sun, 6 Nov 2011 00:44:15 +0100
> Cc: 9960@debbugs.gnu.org
> 
> Ouch. I'm not up to speed to answer all of this.

Eventually, it is best if you try the latest trunk, and deal only with
the problems that are left.

> (Spent the day in a plane to go to some conference near Miami).
> I should be able to check with my copy in a couple of days.

Thanks, we all have our lives.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 05 Nov 2011 16:22:25 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: 9960@debbugs.gnu.org
> 
> "$(THISDIR)/../lib-src/$(BLD)/make-docfile" -d . -g 
> $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp
> 
> This works.

Great.  Does it need to be $(THISDIR) or can it be a literal "."?  The
latter is shorter and easier to understand, if it works.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: 9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 16:23:40 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That comes from Fabrice, assuming that removing `static' doesn't help.
> 
> No, it does not.
> 
> > Does it fail even if you take (1 << 3) in one more level of
> > parentheses?
> 
> Yes.
> 
> > What about an intermediate macro, as in
> >
> >  #define FOO (1 << GCTYPEBITS)
> >  static int __declspec(align(FOO)) test = 1;
> >
> > ?
> 
> Not working. I tried all of these cases in my simple example. It does
> seem to like the shift operator.

I guess Fabrice will have to figure this out.  I'm puzzled how it
worked for him a year ago.

> > Does this go away if you add "#define snprintf _snprintf" to
> > src/s/ms-w32.h, for MSVC only?
> 
> Yes.
> 
> > These are because xdisp.c defines window_box_right `inline'.  (This is
> > an optimized build, right? if not, does it mean that MSVC inlines
> > functions even for a non-optimized builds?)  I would suggest to make
> > that `inline' conditional on _MSC_VER being undefined.
> 
> That worked.
> 
> > Add "#define strtoimax _strtoi64" to src/s/ms-w32.h, conditioned on
> > _MSC_VER.
> 
> Worked.

Please install the 1st and the 3rd of these 3.  I'm about to start a
discussion regarding the 2nd one.

> > Make this (from src/s/ms-w32.h):
> >
> >   #if !defined (_MSC_VER) || (_MSC_VER < 1400)
> >   #define tzname    _tzname
> >
> > be defined unconditionally.  (But leave the "utime" part under the
> > same condition it is today.)
> 
> This is a problem. The ensuing error is:
> 
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\time.h(281) : erro
> r C2090: function returns array
> 
> >From time.h:
> _CRT_INSECURE_DEPRECATE_GLOBALS(_get_tzname) _CRTIMP extern char * tzname[2];

How about using _get_tzname to set up our own private array akin to
tzname[]?  Here's the plan:

 . in src/s/ms-w32.h, "#define tzname msvc_tzname" (for _MSC_VER >= 1400)

 . in w32.c:sys_localtime, when _MSC_VER >= 1400, call _get_tzname
   twice to populate tzname[] with 2 values as expected

 . reinstate HAVE_TZNAME for MSVC

Does this work, i.e. link without errors?

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Christoph Scholtes <cschol2112@googlemail.com>
> Cc: 9960@debbugs.gnu.org
> Date: Sat, 05 Nov 2011 19:50:01 -0600
> 
> I found this old thread dealing with MSVC problems:
> http://old.nabble.com/Compilation-problems-with-latest-MSVC-td8040440.html
> 
> I undef'ed HAVE_TZNAME and it linked, but then crashed when dumping with
> the following error:
> 
> Dumping from obj/i386/temacs.bin
>           to obj/i386/temacs.exe
>         "D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/temacs.exe" -batch
> -l loadup dump
> NMAKE : fatal error U1077: 'D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/temacs.exe' : return code '0xc0000135'
> Stop.

According to my references, 0xc0000135 means "DLL not found".  Can you
try to find out which DLL is that?  Perhaps run `depends' on
temacs.exe and see which DLLs are flagged as not available (note that
1 or 2 are normally absent, you can google them to find out).

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> > Christoph Scholtes <cschol2112@googlemail.com> writes:
> >
> > > Then we get to emacs.c:
> > > emacs.c(537) : error C2059: syntax error : '<<'
> > > emacs.c(537) : error C2059: syntax error : 'constant'
> > > emacs.c(537) : error C2059: syntax error : ')'
> >
> > cl.exe does not like the shift operator in this statement:
> >
> > static int __declspec(align(1 << 3)) test = 1;
>
> That comes from Fabrice, assuming that removing `static' doesn't help.
>
> Does it fail even if you take (1 << 3) in one more level of
> parentheses?
>
> What about an intermediate macro, as in
>
>  #define FOO (1 << GCTYPEBITS)
>  static int __declspec(align(FOO)) test = 1;


Ok. I have to admit that it does not work this way with msvc. Actually, I
can't find a way to make
cl.exe compute the (1<< GCTYPEBITS) before giving it to the align
declaration. At least not with the current release of cl.exe
(16.00.40219.01). I can't check about the previous ones I may have used.

Our best bet is to use a construction like :

#define GCTYPEBITS 4
#if (1<<GCTYPEBITS) == 2
#define ALIGN_GCTYPEBITS 2
#elif (1<<GCTYPEBITS) == 4
#define ALIGN_GCTYPEBITS 4
#elif (1<<GCTYPEBITS) == 8
#define ALIGN_GCTYPEBITS 8
#else
#error Define ALIGN_GCTYPEBITS
#endif

static int __declspec(align(ALIGN_GCTYPEBITS)) test = 1;

void main (int argc, char *argv[]) { }

Sorry but I don't see a shorter answer for the moment.

(Looking into other issues ... and yes I compiled it, I'm using my own
version every day :-) )

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Mon, 7 Nov 2011 17:13:09 +0100
> Cc: Christoph Scholtes <cschol2112@googlemail.com>, 9960@debbugs.gnu.org
> 
> >  #define FOO (1 << GCTYPEBITS)
> >  static int __declspec(align(FOO)) test = 1;
> 
> 
> Ok. I have to admit that it does not work this way with msvc. Actually, I
> can't find a way to make
> cl.exe compute the (1<< GCTYPEBITS) before giving it to the align
> declaration. At least not with the current release of cl.exe
> (16.00.40219.01). I can't check about the previous ones I may have used.
> [...]
> and yes I compiled it, I'm using my own version every day :-)

So you are saying that __declspec(align(1 << GCTYPEBITS)) surely did
work for you with some other version of MSVC?

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Mon, 7 Nov 2011 17:13:09 +0100
> Cc: Christoph Scholtes <cschol2112@googlemail.com>, 9960@debbugs.gnu.org
> 
> Our best bet is to use a construction like :
> 
> #define GCTYPEBITS 4
> #if (1<<GCTYPEBITS) == 2
> #define ALIGN_GCTYPEBITS 2
> #elif (1<<GCTYPEBITS) == 4
> #define ALIGN_GCTYPEBITS 4
> #elif (1<<GCTYPEBITS) == 8
> #define ALIGN_GCTYPEBITS 8
> #else
> #error Define ALIGN_GCTYPEBITS
> #endif
> 
> static int __declspec(align(ALIGN_GCTYPEBITS)) test = 1;

Will this work:

  #define ALIGN_GCTYPEBITS 8
  #if (1 << GCTYPEBITS) != ALIGN_GCTYPEBITS
  #error ALIGN_GCTYPEBITS is wrong!
  #endif
  #define DECL_ALIGN(type, var) \
       type __declspec(align(ALIGN_GCTYPEBITS)) var

Since all this is needed for MSVC alone, we could then move the
ALIGN_GCTYPEBITS definition to src/s/ms-w32.h and leave only the rest
in lisp.h.  WDYT?

bug#9960: fix for Bug#9772 should also help fix Bug#9960

[Paul Eggert]

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

It appears that the patch for Bug#9772 would help fix one of the
problems with the MSVC port (Bug#9960), as the patch solves the problem of
DECL_ALIGN in a portable way that should work with MSVC.

So I updated the Bug#9772 patch to reflect the latest GNU Emacs trunk
(bzr 106319) and am attaching it here.


[-- Attachment #2: stdalign1.txt --]
[-- Type: text/plain, Size: 33872 bytes --]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: eggert@cs.ucla.edu-20111108063537-djz4akhpk4kpoay1
# target_branch: bzr+ssh://eggert@bzr.savannah.gnu.org/emacs/trunk
# testament_sha1: 77a50e154b83c9565cc142f576f81417f67b7e9d
# timestamp: 2011-11-07 22:35:44 -0800
# base_revision_id: monnier@iro.umontreal.ca-20111108025759-\
#   d5u0ag4hdie27lcz
# 
# Begin patch
=== modified file '.bzrignore'
--- .bzrignore	2011-09-29 14:19:11 +0000
+++ .bzrignore	2011-10-17 01:22:19 +0000
@@ -53,6 +53,7 @@
 lib/c++defs.h
 lib/getopt.h
 lib/inttypes.h
+lib/stdalign.h
 lib/stdbool.h
 lib/stdio.h
 lib/stdint.h

=== modified file 'ChangeLog'
--- ChangeLog	2011-11-05 11:34:56 +0000
+++ ChangeLog	2011-11-08 01:07:18 +0000
@@ -1,3 +1,20 @@
+2011-11-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use Gnulib stdalign module (Bug#9772, Bug#9960).
+	This should improve portability of macros like alignof and DECL_ALIGN.
+	* lib/stdalign.in.h, m4/stdalign.m4: New files, from gnulib.
+	* .bzrignore: Add lib/stdalign.h.
+	* Makefile.in (GNULIB_MODULES): Add stdalign.
+	* config.bat: Do not set NO_DECL_ALIGN; no longer needed.
+	Copy lib/stdalign.in.h to lib/stdalign.in-h as needed.
+	* configure.in (HAVE_ATTRIBUTE_ALIGNED): Remove the code that
+	fiddles with this, as gnulib now does this for us.
+	* lib/gnulib.mk, lib/md5.c, lib/sha1.c, lib/sha256.c, lib/sha512.c:
+	* m4/gl-comp.m4, m4/pthread_sigmask.m4: Merge from gnulib.
+
+	* doc/misc/texinfo.tex, lib/gettext.h, lib/gnulib.mk, lib/stdlib.in.h:
+	* m4/include_next.m4, m4/stdlib_h.m4: Merge from gnulib.
+
 2011-11-05  Eli Zaretskii  <eliz@gnu.org>
 
 	* lib/makefile.w32-in (FRC): New dummy target.

=== modified file 'Makefile.in'
--- Makefile.in	2011-09-26 21:30:18 +0000
+++ Makefile.in	2011-10-17 01:22:19 +0000
@@ -337,7 +337,7 @@
   dup2 \
   filemode getloadavg getopt-gnu ignore-value intprops lstat \
   mktime pthread_sigmask readlink \
-  socklen stdarg stdio strftime strtoimax strtoumax symlink sys_stat
+  socklen stdalign stdarg stdio strftime strtoimax strtoumax symlink sys_stat
 GNULIB_TOOL_FLAGS = \
  --avoid=msvc-inval --avoid=msvc-nothrow --avoid=pathmax \
  --avoid=raise --avoid=threadlib \

=== modified file 'config.bat'
--- config.bat	2011-10-31 17:49:10 +0000
+++ config.bat	2011-11-01 05:03:56 +0000
@@ -163,22 +163,6 @@
 if exist ..\autogen\config.in sed -f ../msdos/sed2x.inp < ..\autogen\config.in > config.tmp
 :src4
 sed -f ../msdos/sed2v2.inp <config.tmp >config.h2
-Rem See if DECL_ALIGN can be supported with this GCC
-rm -f junk.c junk.o junk junk.exe
-echo struct { int i; char *p; } __attribute__((__aligned__(8))) foo;  >junk.c
-rem Two percent signs because it is a special character for COMMAND.COM/CMD
-rem Filter thru Sed because "&" is special for CMD.EXE
-echo int main(void) { return (unsigned long)"&"foo %% 8; } | sed "s/.&./\&/"         >>junk.c
-gcc -o junk junk.c
-if not exist junk.exe coff2exe junk
-junk
-If Not ErrorLevel 1 Goto alignOk
-Echo WARNING: Your GCC does not support 8-byte aligned variables.
-Echo WARNING: Therefore Emacs cannot support buffers larger than 128MB.
-rem The following line disables DECL_ALIGN which in turn disables USE_LSB_TAG
-rem For details see lisp.h where it defines USE_LSB_TAG
-echo #define NO_DECL_ALIGN >>config.h2
-:alignOk
 Rem See if they have libxml2 later than v2.2.0 installed
 Echo Checking whether libxml2 v2.2.1 or later is installed ...
 rm -f junk.c junk.o junk junk.exe
@@ -283,6 +267,7 @@
 If Exist build-aux\snippet\c++defs.h update build-aux/snippet/c++defs.h build-aux/snippet/cxxdefs.h
 If Exist alloca.in.h update alloca.in.h alloca.in-h
 If Exist getopt.in.h update getopt.in.h getopt.in-h
+If Exist stdalign.in.h update stdalign.in.h stdalign.in-h
 If Exist stdbool.in.h update stdbool.in.h stdbool.in-h
 If Exist signal.in.h update signal.in.h signal.in-h
 If Exist stddef.in.h update stddef.in.h  stddef.in-h
@@ -346,4 +331,3 @@
 set djgpp_ver=
 set sys_malloc=
 set libxml=
-

=== modified file 'configure.in'
--- configure.in	2011-11-04 22:16:46 +0000
+++ configure.in	2011-11-07 05:59:29 +0000
@@ -1351,19 +1351,6 @@
 dnl Check for endianess
 AC_C_BIGENDIAN
 
-AC_CACHE_CHECK([for  __attribute__ ((__aligned__ (expr)))],
-  [emacs_cv_attribute_aligned],
-  [AC_COMPILE_IFELSE(
-     [AC_LANG_PROGRAM(
-	[[char __attribute__ ((__aligned__ (1 << 3))) c;]],
-	[[]])],
-     [emacs_cv_attribute_aligned=yes],
-     [emacs_cv_attribute_aligned=no])])
-if test $emacs_cv_attribute_aligned = yes; then
-  AC_DEFINE([HAVE_ATTRIBUTE_ALIGNED], 1,
-    [Define to 1 if GCC-style __attribute__ ((__aligned__ (expr))) works.])
-fi
-
 dnl check for Make feature
 AC_PROG_MAKE_SET
 

=== modified file 'doc/misc/ChangeLog'
--- doc/misc/ChangeLog	2011-11-01 19:22:57 +0000
+++ doc/misc/ChangeLog	2011-11-08 01:07:18 +0000
@@ -1,3 +1,7 @@
+2011-11-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	* texinfo.tex: Merge from gnulib.
+
 2011-10-31  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* gnus.texi (Other Gnus Versions): Remove.

=== modified file 'doc/misc/texinfo.tex'
--- doc/misc/texinfo.tex	2011-09-26 21:30:18 +0000
+++ doc/misc/texinfo.tex	2011-11-07 05:56:04 +0000
@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2011-09-23.09}
+\def\texinfoversion{2011-11-06.09}
 %
 % Copyright 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -116,6 +116,7 @@
 % Set up fixed words for English if not already set.
 \ifx\putwordAppendix\undefined  \gdef\putwordAppendix{Appendix}\fi
 \ifx\putwordChapter\undefined   \gdef\putwordChapter{Chapter}\fi
+\ifx\putworderror\undefined     \gdef\putwordfile{error}\fi
 \ifx\putwordfile\undefined      \gdef\putwordfile{file}\fi
 \ifx\putwordin\undefined        \gdef\putwordin{in}\fi
 \ifx\putwordIndexIsEmpty\undefined       \gdef\putwordIndexIsEmpty{(Index is empty)}\fi
@@ -1194,29 +1195,31 @@
     \def\imagewidth{#2}\setbox0 = \hbox{\ignorespaces #2}%
     \def\imageheight{#3}\setbox2 = \hbox{\ignorespaces #3}%
     %
-    % pdftex (and the PDF format) support .png, .jpg, .pdf (among
-    % others).  Let's try in that order.
+    % pdftex (and the PDF format) support .pdf, .png, .jpg (among
+    % others).  Let's try in that order, PDF first since if
+    % someone has a scalable image, presumably better to use that than a
+    % bitmap.
     \let\pdfimgext=\empty
     \begingroup
-      \openin 1 #1.png \ifeof 1
-        \openin 1 #1.jpg \ifeof 1
-          \openin 1 #1.jpeg \ifeof 1
-            \openin 1 #1.JPG \ifeof 1
-              \openin 1 #1.pdf \ifeof 1
-                \openin 1 #1.PDF \ifeof 1
+      \openin 1 #1.pdf \ifeof 1
+        \openin 1 #1.PDF \ifeof 1
+          \openin 1 #1.png \ifeof 1
+            \openin 1 #1.jpg \ifeof 1
+              \openin 1 #1.jpeg \ifeof 1
+                \openin 1 #1.JPG \ifeof 1
                   \errhelp = \nopdfimagehelp
                   \errmessage{Could not find image file #1 for pdf}%
-                \else \gdef\pdfimgext{PDF}%
+                \else \gdef\pdfimgext{JPG}%
                 \fi
-              \else \gdef\pdfimgext{pdf}%
+              \else \gdef\pdfimgext{jpeg}%
               \fi
-            \else \gdef\pdfimgext{JPG}%
+            \else \gdef\pdfimgext{jpg}%
             \fi
-          \else \gdef\pdfimgext{jpeg}%
+          \else \gdef\pdfimgext{png}%
           \fi
-        \else \gdef\pdfimgext{jpg}%
+        \else \gdef\pdfimgext{PDF}%
         \fi
-      \else \gdef\pdfimgext{png}%
+      \else \gdef\pdfimgext{pdf}%
       \fi
       \closein 1
     \endgroup
@@ -2372,7 +2375,9 @@
   \else\ifx\next-%
   \else\ifx\next.%
   \else\ptexslash
-  \fi\fi\fi}
+  \fi\fi\fi
+  \aftersmartic
+}
 
 % like \smartslanted except unconditionally uses \ttsl, and no ic.
 % @var is set to this for defun arguments.
@@ -2382,9 +2387,15 @@
 % ttsl for book titles, do we?
 \def\cite#1{{\sl #1}\futurelet\next\smartitaliccorrection}
 
+\def\aftersmartic{}
+\def\var#1{%
+  \let\saveaftersmartic = \aftersmartic
+  \def\aftersmartic{\null\let\aftersmartic=\saveaftersmartic}%
+  \smartslanted{#1}%
+}
+
 \let\i=\smartitalic
 \let\slanted=\smartslanted
-\def\var#1{\smartslanted{#1}}
 \let\dfn=\smartslanted
 \let\emph=\smartitalic
 
@@ -2480,7 +2491,7 @@
     \plainfrenchspacing
     #1%
   }%
-  \null
+  \null % reset spacefactor to 1000
 }
 
 % We *must* turn on hyphenation at `-' and `_' in @code.
@@ -2762,6 +2773,7 @@
   \ifx\temp\empty \else
     \space ({\unsepspaces \ignorespaces \temp \unskip})%
   \fi
+  \null % reset \spacefactor=1000
 }
 
 % @abbr for "Comput. J." and the like.
@@ -2774,6 +2786,7 @@
   \ifx\temp\empty \else
     \space ({\unsepspaces \ignorespaces \temp \unskip})%
   \fi
+  \null % reset \spacefactor=1000
 }
 
 % @asis just yields its argument.  Used with @table, for example.
@@ -2979,7 +2992,7 @@
 {\tentt \global\dimen0 = 3em}% Width of the box.
 \dimen2 = .55pt % Thickness of rules
 % The text. (`r' is open on the right, `e' somewhat less so on the left.)
-\setbox0 = \hbox{\kern-.75pt \reducedsf error\kern-1.5pt}
+\setbox0 = \hbox{\kern-.75pt \reducedsf \putworderror\kern-1.5pt}
 %
 \setbox\errorbox=\hbox to \dimen0{\hfil
    \hsize = \dimen0 \advance\hsize by -5.8pt % Space to left+right.
@@ -8103,7 +8116,7 @@
 % space to prevent strange expansion errors.)
 \def\supereject{\par\penalty -20000\footnoteno =0 }
 
-% @footnotestyle is meaningful for info output only.
+% @footnotestyle is meaningful for Info output only.
 \let\footnotestyle=\comment
 
 {\catcode `\@=11
@@ -8166,6 +8179,8 @@
   % expands into a box, it must come within the paragraph, lest it
   % provide a place where TeX can split the footnote.
   \footstrut
+  %
+  % Invoke rest of plain TeX footnote routine.
   \futurelet\next\fo@t
 }
 }%end \catcode `\@=11

=== modified file 'lib/gettext.h'
--- lib/gettext.h	2011-02-15 04:53:29 +0000
+++ lib/gettext.h	2011-10-27 19:51:26 +0000
@@ -185,7 +185,7 @@
 #include <string.h>
 
 #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
-  (((__GNUC__ >= 3 || __GNUG__ >= 2) && !__STRICT_ANSI__) \
+  (((__GNUC__ >= 3 || __GNUG__ >= 2) && !defined __STRICT_ANSI__) \
    /* || __STDC_VERSION__ >= 199901L */ )
 
 #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS

=== modified file 'lib/gnulib.mk'
--- lib/gnulib.mk	2011-09-26 21:30:18 +0000
+++ lib/gnulib.mk	2011-10-27 19:51:26 +0000
@@ -21,7 +21,7 @@
 # the same distribution terms as the rest of that program.
 #
 # Generated by gnulib-tool.
-# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=lib --m4-base=m4 --doc-base=doc --tests-base=tests --aux-dir=build-aux --avoid=msvc-inval --avoid=msvc-nothrow --avoid=pathmax --avoid=raise --avoid=threadlib --makefile-name=gnulib.mk --conditional-dependencies --no-libtool --macro-prefix=gl --no-vc-files alloca-opt careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr dup2 filemode getloadavg getopt-gnu ignore-value intprops lstat mktime pthread_sigmask readlink socklen stdarg stdio strftime strtoimax strtoumax symlink sys_stat
+# Reproduce by: gnulib-tool --import --dir=. --lib=libgnu --source-base=lib --m4-base=m4 --doc-base=doc --tests-base=tests --aux-dir=build-aux --avoid=msvc-inval --avoid=msvc-nothrow --avoid=pathmax --avoid=raise --avoid=threadlib --makefile-name=gnulib.mk --conditional-dependencies --no-libtool --macro-prefix=gl --no-vc-files alloca-opt careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr dup2 filemode getloadavg getopt-gnu ignore-value intprops lstat mktime pthread_sigmask readlink socklen stdalign stdarg stdio strftime strtoimax strtoumax symlink sys_stat
 
 
 MOSTLYCLEANFILES += core *.stackdump
@@ -421,6 +421,29 @@
 
 ## end   gnulib module stat
 
+## begin gnulib module stdalign
+
+BUILT_SOURCES += $(STDALIGN_H)
+
+# We need the following in order to create <stdalign.h> when the system
+# doesn't have one that works.
+if GL_GENERATE_STDALIGN_H
+stdalign.h: stdalign.in.h $(top_builddir)/config.status
+	$(AM_V_GEN)rm -f $@-t $@ && \
+	{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
+	  cat $(srcdir)/stdalign.in.h; \
+	} > $@-t && \
+	mv $@-t $@
+else
+stdalign.h: $(top_builddir)/config.status
+	rm -f $@
+endif
+MOSTLYCLEANFILES += stdalign.h stdalign.h-t
+
+EXTRA_DIST += stdalign.in.h
+
+## end   gnulib module stdalign
+
 ## begin gnulib module stdarg
 
 BUILT_SOURCES += $(STDARG_H)
@@ -710,6 +733,7 @@
 	      -e 's/@''GNULIB_MKOSTEMPS''@/$(GNULIB_MKOSTEMPS)/g' \
 	      -e 's/@''GNULIB_MKSTEMP''@/$(GNULIB_MKSTEMP)/g' \
 	      -e 's/@''GNULIB_MKSTEMPS''@/$(GNULIB_MKSTEMPS)/g' \
+	      -e 's/@''GNULIB_POSIX_OPENPT''@/$(GNULIB_POSIX_OPENPT)/g' \
 	      -e 's/@''GNULIB_PTSNAME''@/$(GNULIB_PTSNAME)/g' \
 	      -e 's/@''GNULIB_PUTENV''@/$(GNULIB_PUTENV)/g' \
 	      -e 's/@''GNULIB_RANDOM_R''@/$(GNULIB_RANDOM_R)/g' \
@@ -736,6 +760,7 @@
 	      -e 's|@''HAVE_MKOSTEMPS''@|$(HAVE_MKOSTEMPS)|g' \
 	      -e 's|@''HAVE_MKSTEMP''@|$(HAVE_MKSTEMP)|g' \
 	      -e 's|@''HAVE_MKSTEMPS''@|$(HAVE_MKSTEMPS)|g' \
+	      -e 's|@''HAVE_POSIX_OPENPT''@|$(HAVE_POSIX_OPENPT)|g' \
 	      -e 's|@''HAVE_PTSNAME''@|$(HAVE_PTSNAME)|g' \
 	      -e 's|@''HAVE_RANDOM_H''@|$(HAVE_RANDOM_H)|g' \
 	      -e 's|@''HAVE_RANDOM_R''@|$(HAVE_RANDOM_R)|g' \

=== modified file 'lib/md5.c'
--- lib/md5.c	2011-02-19 07:28:29 +0000
+++ lib/md5.c	2011-10-17 01:22:19 +0000
@@ -24,7 +24,8 @@
 
 #include "md5.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 #include <sys/types.h>
@@ -254,8 +255,7 @@
   if (len >= 64)
     {
 #if !_STRING_ARCH_unaligned
-# define alignof(type) offsetof (struct { char c; type x; }, x)
-# define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
+# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) != 0)
       if (UNALIGNED_P (buffer))
         while (len > 64)
           {

=== modified file 'lib/sha1.c'
--- lib/sha1.c	2011-05-24 08:12:52 +0000
+++ lib/sha1.c	2011-10-17 01:22:19 +0000
@@ -26,7 +26,8 @@
 
 #include "sha1.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -241,8 +242,7 @@
   if (len >= 64)
     {
 #if !_STRING_ARCH_unaligned
-# define alignof(type) offsetof (struct { char c; type x; }, x)
-# define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
+# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) != 0)
       if (UNALIGNED_P (buffer))
         while (len > 64)
           {

=== modified file 'lib/sha256.c'
--- lib/sha256.c	2011-06-21 08:45:39 +0000
+++ lib/sha256.c	2011-10-17 01:22:19 +0000
@@ -24,7 +24,8 @@
 
 #include "sha256.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -373,8 +374,7 @@
   if (len >= 64)
     {
 #if !_STRING_ARCH_unaligned
-# define alignof(type) offsetof (struct { char c; type x; }, x)
-# define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
+# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) != 0)
       if (UNALIGNED_P (buffer))
         while (len > 64)
           {

=== modified file 'lib/sha512.c'
--- lib/sha512.c	2011-06-21 08:45:39 +0000
+++ lib/sha512.c	2011-10-17 01:22:19 +0000
@@ -24,7 +24,8 @@
 
 #include "sha512.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -381,8 +382,7 @@
   if (len >= 128)
     {
 #if !_STRING_ARCH_unaligned
-# define alignof(type) offsetof (struct { char c; type x; }, x)
-# define UNALIGNED_P(p) (((size_t) p) % alignof (u64) != 0)
+# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (u64) != 0)
       if (UNALIGNED_P (buffer))
         while (len > 128)
           {

=== added file 'lib/stdalign.in.h'
--- lib/stdalign.in.h	1970-01-01 00:00:00 +0000
+++ lib/stdalign.in.h	2011-11-07 05:56:04 +0000
@@ -0,0 +1,89 @@
+/* A substitute for ISO C 1x <stdalign.h>.
+
+   Copyright 2011 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+/* Written by Paul Eggert and Bruno Haible.  */
+
+#ifndef _GL_STDALIGN_H
+#define _GL_STDALIGN_H
+
+/* ISO C1X <stdalign.h> for platforms that lack it.
+
+   References:
+   ISO C1X <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
+   sections 6.5.3.4, 6.7.5, 7.15.
+   C++0X <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf>
+   section 18.10. */
+
+/* alignof (TYPE), also known as _Alignof (TYPE), yields the alignment
+   requirement of a structure member (i.e., slot or field) that is of
+   type TYPE, as an integer constant expression.
+
+   This differs from GCC's __alignof__ operator, which can yield a
+   better-performing alignment for an object of that type.  For
+   example, on x86 with GCC, __alignof__ (double) and __alignof__
+   (long long) are 8, whereas alignof (double) and alignof (long long)
+   are 4 unless the option '-malign-double' is used.
+
+   The result cannot be used as a value for an 'enum' constant, if you
+   want to be portable to HP-UX 10.20 cc and AIX 3.2.5 xlc.  */
+#include <stddef.h>
+#if defined __cplusplus
+   template <class __t> struct __alignof_helper { char __a; __t __b; };
+# define _Alignof(type) offsetof (__alignof_helper<type>, __b)
+#else
+# define _Alignof(type) offsetof (struct { char __a; type __b; }, __b)
+#endif
+#define alignof _Alignof
+#define __alignof_is_defined 1
+
+/* alignas (A), also known as _Alignas (A), aligns a variable or type
+   to the alignment A, where A is an integer constant expression.  For
+   example:
+
+      int alignas (8) foo;
+      struct s { int a; int alignas (8) bar; };
+
+   aligns the address of FOO and the offset of BAR to be multiples of 8.
+
+   A should be a power of two that is at least the type's alignment
+   and at most the implementation's alignment limit.  This limit is
+   2**28 on typical GNUish hosts, and 2**13 on MSVC.  To be portable
+   to MSVC through at least version 10.0, A should be an integer
+   constant, as MSVC does not support expressions such as 1 << 3.
+   To be portable to Sun C 5.11, do not align auto variables to
+   anything stricter than their default alignment.
+
+   The following draft C1X requirements are not supported here:
+
+     - If A is zero, alignas has no effect.
+     - alignas can be used multiple times; the strictest one wins.
+     - alignas (TYPE) is equivalent to alignas (alignof (TYPE)).
+
+   */
+
+#if __GNUC__ || __IBMC__ || __IBMCPP__ || 0x5110 <= __SUNPRO_C
+# define _Alignas(a) __attribute__ ((__aligned__ (a)))
+#elif 1300 <= _MSC_VER
+# define _Alignas(a) __declspec (align (a))
+#endif
+#ifdef _Alignas
+# define alignas _Alignas
+# define __alignas_is_defined 1
+#endif
+
+#endif /* _GL_STDALIGN_H */

=== modified file 'lib/stdlib.in.h'
--- lib/stdlib.in.h	2011-07-24 22:15:47 +0000
+++ lib/stdlib.in.h	2011-11-08 01:12:08 +0000
@@ -247,7 +247,7 @@
 #elif defined GNULIB_POSIXCHECK
 # undef grantpt
 # if HAVE_RAW_DECL_GRANTPT
-_GL_WARN_ON_USE (ptsname, "grantpt is not portable - "
+_GL_WARN_ON_USE (grantpt, "grantpt is not portable - "
                  "use gnulib module grantpt for portability");
 # endif
 #endif
@@ -423,6 +423,22 @@
 # endif
 #endif
 
+#if @GNULIB_POSIX_OPENPT@
+/* Return an FD open to the master side of a pseudo-terminal.  Flags should
+   include O_RDWR, and may also include O_NOCTTY.  */
+# if !@HAVE_POSIX_OPENPT@
+_GL_FUNCDECL_SYS (posix_openpt, int, (int flags));
+# endif
+_GL_CXXALIAS_SYS (posix_openpt, int, (int flags));
+_GL_CXXALIASWARN (posix_openpt);
+#elif defined GNULIB_POSIXCHECK
+# undef posix_openpt
+# if HAVE_RAW_DECL_POSIX_OPENPT
+_GL_WARN_ON_USE (posix_openpt, "posix_openpt is not portable - "
+                 "use gnulib module posix_openpt for portability");
+# endif
+#endif
+
 #if @GNULIB_PTSNAME@
 /* Return the pathname of the pseudo-terminal slave associated with
    the master FD is open on, or NULL on errors.  */

=== modified file 'm4/gl-comp.m4'
--- m4/gl-comp.m4	2011-10-07 21:15:00 +0000
+++ m4/gl-comp.m4	2011-10-17 01:22:19 +0000
@@ -76,6 +76,7 @@
   # Code from module socklen:
   # Code from module ssize_t:
   # Code from module stat:
+  # Code from module stdalign:
   # Code from module stdarg:
   dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
   dnl for the builtin va_copy to work.  With Autoconf 2.60 or later,
@@ -180,6 +181,7 @@
 gl_SIGNAL_H
 gl_TYPE_SOCKLEN_T
 gt_TYPE_SSIZE_T
+gl_STDALIGN_H
 gl_STDARG_H
 AM_STDBOOL_H
 gl_STDDEF_H
@@ -311,18 +313,18 @@
   if test $HAVE_READLINK = 0 || test $REPLACE_READLINK = 1; then
     func_gl_gnulib_m4code_stat
   fi
-  if test $ac_cv_func_strtoimax = no; then
-    func_gl_gnulib_m4code_verify
-  fi
   if test $ac_cv_func_strtoimax = no && test $ac_cv_type_long_long_int = yes; then
     func_gl_gnulib_m4code_strtoll
   fi
-  if test $ac_cv_func_strtoumax = no; then
+  if test $ac_cv_func_strtoimax = no; then
     func_gl_gnulib_m4code_verify
   fi
   if test $ac_cv_func_strtoumax = no && test $ac_cv_type_unsigned_long_long_int = yes; then
     func_gl_gnulib_m4code_strtoull
   fi
+  if test $ac_cv_func_strtoumax = no; then
+    func_gl_gnulib_m4code_verify
+  fi
   m4_pattern_allow([^gl_GNULIB_ENABLED_])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_dosname], [$gl_gnulib_enabled_dosname])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_be453cec5eecf5731a274f2de7f2db36], [$gl_gnulib_enabled_be453cec5eecf5731a274f2de7f2db36])
@@ -513,6 +515,7 @@
   lib/signal.in.h
   lib/sigprocmask.c
   lib/stat.c
+  lib/stdalign.in.h
   lib/stdarg.in.h
   lib/stdbool.in.h
   lib/stddef.in.h
@@ -563,6 +566,7 @@
   m4/ssize_t.m4
   m4/st_dm_mode.m4
   m4/stat.m4
+  m4/stdalign.m4
   m4/stdarg.m4
   m4/stdbool.m4
   m4/stddef_h.m4

=== modified file 'm4/include_next.m4'
--- m4/include_next.m4	2011-09-26 21:30:18 +0000
+++ m4/include_next.m4	2011-10-27 19:51:26 +0000
@@ -1,4 +1,4 @@
-# include_next.m4 serial 22
+# include_next.m4 serial 23
 dnl Copyright (C) 2006-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -219,12 +219,17 @@
                    gl_dirsep_regex='[/\\]'
                    ;;
                  *)
-                   gl_dirsep_regex='/'
+                   gl_dirsep_regex='\/'
                    ;;
                esac
+               dnl A sed expression that turns a string into a basic regular
+               dnl expression, for use within "/.../".
+               gl_make_literal_regex_sed='s,[]$^\\.*/[],\\&,g'
 changequote([,])
-               gl_absolute_header_sed='\|'"${gl_dirsep_regex}"']m4_defn([gl_HEADER_NAME])[|{
-                   s|.*"\(.*'"${gl_dirsep_regex}"']m4_defn([gl_HEADER_NAME])[\)".*|\1|
+               gl_header_literal_regex=`echo ']m4_defn([gl_HEADER_NAME])[' \
+                                        | sed -e "$gl_make_literal_regex_sed"`
+               gl_absolute_header_sed="/${gl_dirsep_regex}${gl_header_literal_regex}/"'{
+                   s/.*"\(.*'"${gl_dirsep_regex}${gl_header_literal_regex}"'\)".*/\1/
 changequote(,)dnl
                    s|^/[^/]|//&|
 changequote([,])dnl

=== modified file 'm4/pthread_sigmask.m4'
--- m4/pthread_sigmask.m4	2011-09-03 23:08:32 +0000
+++ m4/pthread_sigmask.m4	2011-10-17 01:22:19 +0000
@@ -1,4 +1,4 @@
-# pthread_sigmask.m4 serial 12
+# pthread_sigmask.m4 serial 13
 dnl Copyright (C) 2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -6,6 +6,8 @@
 
 AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
 [
+  AC_REQUIRE([gl_SIGNAL_H_DEFAULTS])
+
   AC_CHECK_FUNCS_ONCE([pthread_sigmask])
   LIB_PTHREAD_SIGMASK=
 

=== added file 'm4/stdalign.m4'
--- m4/stdalign.m4	1970-01-01 00:00:00 +0000
+++ m4/stdalign.m4	2011-10-27 19:39:30 +0000
@@ -0,0 +1,22 @@
+# Check for stdalign.h that conforms to C1x.
+
+dnl Copyright 2011 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+# Prepare for substituting <stdalign.h> if it is not supported.
+
+AC_DEFUN([gl_STDALIGN_H],
+[
+  AC_CHECK_HEADERS_ONCE([stdalign.h])
+
+  if test $ac_cv_header_stdalign_h = yes; then
+    STDALIGN_H=''
+  else
+    STDALIGN_H='stdalign.h'
+  fi
+
+  AC_SUBST([STDALIGN_H])
+  AM_CONDITIONAL([GL_GENERATE_STDALIGN_H], [test -n "$STDALIGN_H"])
+])

=== modified file 'm4/stdlib_h.m4'
--- m4/stdlib_h.m4	2011-02-25 07:36:37 +0000
+++ m4/stdlib_h.m4	2011-10-27 19:51:26 +0000
@@ -19,10 +19,10 @@
 #if HAVE_RANDOM_H
 # include <random.h>
 #endif
-    ]], [_Exit atoll canonicalize_file_name getloadavg getsubopt grantpt mkdtemp
-    mkostemp mkostemps mkstemp mkstemps ptsname random_r initstat_r srandom_r
-    setstate_r realpath rpmatch setenv strtod strtoll strtoull unlockpt
-    unsetenv])
+    ]], [_Exit atoll canonicalize_file_name getloadavg getsubopt grantpt
+    initstate_r mkdtemp mkostemp mkostemps mkstemp mkstemps posix_openpt
+    ptsname random_r realpath rpmatch setenv setstate_r srandom_r strtod
+    strtoll strtoull unlockpt unsetenv])
 ])
 
 AC_DEFUN([gl_STDLIB_MODULE_INDICATOR],
@@ -50,6 +50,7 @@
   GNULIB_MKOSTEMPS=0;     AC_SUBST([GNULIB_MKOSTEMPS])
   GNULIB_MKSTEMP=0;       AC_SUBST([GNULIB_MKSTEMP])
   GNULIB_MKSTEMPS=0;      AC_SUBST([GNULIB_MKSTEMPS])
+  GNULIB_POSIX_OPENPT=0;  AC_SUBST([GNULIB_POSIX_OPENPT])
   GNULIB_PTSNAME=0;       AC_SUBST([GNULIB_PTSNAME])
   GNULIB_PUTENV=0;        AC_SUBST([GNULIB_PUTENV])
   GNULIB_RANDOM_R=0;      AC_SUBST([GNULIB_RANDOM_R])
@@ -76,6 +77,7 @@
   HAVE_MKOSTEMPS=1;          AC_SUBST([HAVE_MKOSTEMPS])
   HAVE_MKSTEMP=1;            AC_SUBST([HAVE_MKSTEMP])
   HAVE_MKSTEMPS=1;           AC_SUBST([HAVE_MKSTEMPS])
+  HAVE_POSIX_OPENPT=1;       AC_SUBST([HAVE_POSIX_OPENPT])
   HAVE_PTSNAME=1;            AC_SUBST([HAVE_PTSNAME])
   HAVE_RANDOM_H=1;           AC_SUBST([HAVE_RANDOM_H])
   HAVE_RANDOM_R=1;           AC_SUBST([HAVE_RANDOM_R])

=== modified file 'msdos/ChangeLog'
--- msdos/ChangeLog	2011-10-31 17:37:39 +0000
+++ msdos/ChangeLog	2011-11-08 06:35:37 +0000
@@ -1,3 +1,10 @@
+2011-11-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use Gnulib stdalign module (Bug#9772, Bug#9960).
+	* sed2v2.inp (HAVE_ATTRIBUTE_ALIGNED): Remove edit.
+	* sedlibmk.inp (STDALIGN_H, @GL_GENERATE_STDALIGN_H_TRUE@)
+	(GL_GENERATE_STDALIGN_H_FALSE): New edits.
+
 2011-10-31  Eli Zaretskii  <eliz@gnu.org>
 
 	* sed3v2.inp (insrcdir): Comment out definition.

=== modified file 'msdos/sed2v2.inp'
--- msdos/sed2v2.inp	2011-10-31 02:25:01 +0000
+++ msdos/sed2v2.inp	2011-11-01 05:03:56 +0000
@@ -35,7 +35,6 @@
 /^#undef HAVE_FREXP *$/s/^.*$/#define HAVE_FREXP 1/
 /^#undef HAVE_FMOD *$/s/^.*$/#define HAVE_FMOD 1/
 /^#undef HAVE_RINT *$/s/^.*$/#define HAVE_RINT 1/
-/^#undef HAVE_ATTRIBUTE_ALIGNED *$/s/^.*$/#define HAVE_ATTRIBUTE_ALIGNED 1/
 /^#undef HAVE_C99_STRTOLD *$/s/^.*$/#define HAVE_C99_STRTOLD 1/
 /^#undef HAVE_CBRT *$/s/^.*$/#define HAVE_CBRT 1/
 /^#undef HAVE_DIFFTIME *$/s/^.*$/#define HAVE_DIFFTIME 1/
@@ -119,4 +118,3 @@
 # might be defined in sys/config.h we include at the top of config.h.
 /^#undef BSTRING/s|#undef|# undef|
 /^#undef .*$/s|^.*$|/* & */|
-

=== modified file 'msdos/sedlibmk.inp'
--- msdos/sedlibmk.inp	2011-09-29 12:00:18 +0000
+++ msdos/sedlibmk.inp	2011-10-17 01:22:19 +0000
@@ -27,7 +27,7 @@
 #    otherwise edit them to zero:
 #
 #     /^REPLACE_CALLOC *=/s/@REPLACE_CALLOC@/0/
-# 
+#
 #  . If the module is a header or adds headers, edit the corresponding
 #    variable to either an empty value or to the name of the header.
 #    Examples:
@@ -547,6 +547,7 @@
 /^SIZE_T_SUFFIX *=/s/@SIZE_T_SUFFIX@/u/
 /^ALLOCA_H *=/s/@[^@\n]*@/alloca.h/
 /^STDBOOL_H *=/s/@[^@\n]*@//
+/^STDALIGN_H *=/s/@[^@\n]*@/stdalign.h/
 /^STDARG_H *=/s/@[^@\n]*@//
 /^STDDEF_H *=/s/@[^@\n]*@//
 /^STDINT_H *=/s/@[^@\n]*@/stdint.h/
@@ -600,6 +601,8 @@
 s/^@GL_GENERATE_ALLOCA_H_FALSE@/\#/
 s/^@GL_GENERATE_STDBOOL_H_TRUE@/\#/
 s/^@GL_GENERATE_STDBOOL_H_FALSE@//
+s/^@GL_GENERATE_STDALIGN_H_TRUE@//
+s/^@GL_GENERATE_STDALIGN_H_FALSE@/\#/
 s/^@GL_GENERATE_STDARG_H_TRUE@/\#/
 s/^@GL_GENERATE_STDARG_H_FALSE@/\#/
 s/^@GL_GENERATE_STDDEF_H_TRUE@/\#/

=== modified file 'nt/ChangeLog'
--- nt/ChangeLog	2011-11-05 22:33:44 +0000
+++ nt/ChangeLog	2011-11-08 06:35:37 +0000
@@ -1,3 +1,8 @@
+2011-11-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use Gnulib stdalign module (Bug#9772, Bug#9960).
+	* config.nt (HAVE_ATTRIBUTE_ALIGNED): Remove.
+
 2011-11-05  Christoph Scholtes  <cschol2112@googlemail.com>
 
 	* inc/stdint.h (UINT64_MAX, UINT64_MIN, INT64_MIN, UINTMAX_MAX)

=== modified file 'nt/config.nt'
--- nt/config.nt	2011-11-05 17:16:01 +0000
+++ nt/config.nt	2011-11-07 05:59:29 +0000
@@ -278,13 +278,6 @@
 
 /* Preprocessor macros needed for gnulib imports.  */
 
-/* Define to 1 if GCC-style __attribute__ ((__aligned__ (expr))) works. */
-#ifdef __GNUC__
-#define HAVE_ATTRIBUTE_ALIGNED 1
-#else
-#undef HAVE_ATTRIBUTE_ALIGNED
-#endif
-
 /* Define to 1 if strtold conforms to C99. */
 #ifdef __GNUC__
 #define HAVE_C99_STRTOLD 1

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-11-07 17:04:01 +0000
+++ src/ChangeLog	2011-11-08 06:35:37 +0000
@@ -1,3 +1,14 @@
+2011-11-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use Gnulib stdalign module (Bug#9772, Bug#9960).
+	* alloc.c (XMALLOC_BASE_ALIGNMENT, GC_LISP_OBJECT_ALIGNMENT)
+	(GC_POINTER_ALIGNMENT, pure_alloc): Simplify by using alignof.
+	(pure_alloc) [! USE_LSB_TAG]: Don't over-align EMACS_INT values.
+	* lisp.h: Include <stdalign.h>.
+	(DECL_ALIGN): Simplify by using alignas.
+	Port to MSVC, by using ALIGN_GCTYPEBITS.
+	(ALIGN_GCTYPEBITS): New macro.
+
 2011-11-07  Juanma Barranquero  <lekktu@gmail.com>
 
 	* lisp.h (syms_of_abbrev): Remove declaration.

=== modified file 'src/alloc.c'
--- src/alloc.c	2011-11-07 05:37:49 +0000
+++ src/alloc.c	2011-11-07 05:59:29 +0000
@@ -513,12 +513,7 @@
    hold a size_t value and (2) the header size is a multiple of the
    alignment that Emacs needs for C types and for USE_LSB_TAG.  */
 #define XMALLOC_BASE_ALIGNMENT				\
-  offsetof (						\
-    struct {						\
-      union { long double d; intmax_t i; void *p; } u;	\
-      char c;						\
-    },							\
-    c)
+  alignof (union { long double d; intmax_t i; void *p; })
 #ifdef USE_LSB_TAG
 /* A common multiple of the positive integers A and B.  Ideally this
    would be the least common multiple, but there's no way to do that
@@ -4241,15 +4236,15 @@
 }
 
 
-/* Alignment of Lisp_Object and pointer values.  Use offsetof, as it
+/* Alignment of Lisp_Object and pointer values.  Use alignof, as it
    sometimes returns a smaller alignment than GCC's __alignof__ and
    mark_memory might miss objects if __alignof__ were used.  For
    example, on x86 with WIDE_EMACS_INT, __alignof__ (Lisp_Object) is 8
    but GC_LISP_OBJECT_ALIGNMENT should be 4.  */
 #ifndef GC_LISP_OBJECT_ALIGNMENT
-# define GC_LISP_OBJECT_ALIGNMENT offsetof (struct {char a; Lisp_Object b;}, b)
+# define GC_LISP_OBJECT_ALIGNMENT alignof (Lisp_Object)
 #endif
-#define GC_POINTER_ALIGNMENT offsetof (struct {char a; void *b;}, b)
+#define GC_POINTER_ALIGNMENT alignof (void *)
 
 /* Mark Lisp objects referenced from the address range START+OFFSET..END
    or END+OFFSET..START. */
@@ -4668,17 +4663,11 @@
 #ifdef USE_LSB_TAG
   size_t alignment = (1 << GCTYPEBITS);
 #else
-  size_t alignment = sizeof (EMACS_INT);
+  size_t alignment = alignof (EMACS_INT);
 
   /* Give Lisp_Floats an extra alignment.  */
   if (type == Lisp_Float)
-    {
-#if defined __GNUC__ && __GNUC__ >= 2
-      alignment = __alignof (struct Lisp_Float);
-#else
-      alignment = sizeof (struct Lisp_Float);
-#endif
-    }
+    alignment = alignof (struct Lisp_Float);
 #endif
 
  again:

=== modified file 'src/lisp.h'
--- src/lisp.h	2011-11-07 17:04:01 +0000
+++ src/lisp.h	2011-11-08 01:07:18 +0000
@@ -20,6 +20,7 @@
 #ifndef EMACS_LISP_H
 #define EMACS_LISP_H
 
+#include <stdalign.h>
 #include <stdarg.h>
 #include <stddef.h>
 #include <inttypes.h>
@@ -163,18 +164,8 @@
 /* First, try and define DECL_ALIGN(type,var) which declares a static
    variable VAR of type TYPE with the added requirement that it be
    TYPEBITS-aligned.  */
-#ifndef NO_DECL_ALIGN
-# ifndef DECL_ALIGN
-#  if HAVE_ATTRIBUTE_ALIGNED
-#   define DECL_ALIGN(type, var) \
-     type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var
-#  elif defined(_MSC_VER)
-#   define DECL_ALIGN(type, var) \
-     type __declspec(align(1 << GCTYPEBITS)) var
-#  else
-     /* What directives do other compilers use?  */
-#  endif
-# endif
+#ifdef alignas
+# define DECL_ALIGN(type, var) type alignas (ALIGN_GCTYPEBITS) var
 #endif
 
 /* Let's USE_LSB_TAG on systems where we know malloc returns mult-of-8.  */
@@ -302,6 +293,10 @@
 
 #ifndef GCTYPEBITS
 #define GCTYPEBITS 3
+#define ALIGN_GCTYPEBITS 8 /* This must be an integer constant, for MSVC.  */
+#endif
+#if 1 << GCTYPEBITS != ALIGN_GCTYPEBITS
+# error "ALIGN_GCTYPEBITS is wrong!"
 #endif
 
 /* These values are overridden by the m- file on some machines.  */

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Tue, 8 Nov 2011 16:36:42 +0100
> 
> Back to the current version, I managed to compile and bootstrap it.

Please tell how you overcame the problems Christoph had, described
here:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#71
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#77

And please keep the debbugs address on the CC list, so this discussion
gets archived in the bug tracker.

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

2011/11/7 Eli Zaretskii <eliz@gnu.org>

> Will this work:
>
>  #define ALIGN_GCTYPEBITS 8
>  #if (1 << GCTYPEBITS) != ALIGN_GCTYPEBITS
>  #error ALIGN_GCTYPEBITS is wrong!
>  #endif
>  #define DECL_ALIGN(type, var) \
>       type __declspec(align(ALIGN_GCTYPEBITS)) var
>
> Since all this is needed for MSVC alone, we could then move the
> ALIGN_GCTYPEBITS definition to src/s/ms-w32.h and leave only the rest
> in lisp.h.  WDYT?
>

Sure. feel free to adapt on the basis of the attached patch.
Status is :
- completely functional 32 bits version with xpm, gif, jpeg, tiff. Able to
boostrap itself.
- the 64 bits version compiles and dumps, but fails to bootstrap (seems to
be looping inside elisp code).

Is there any interest in having a 64bits windows emacs ?

I have added two other files : a 64bits manifest for emacs.exe and a
w32compat.h header file that is needed to compile the above mentioned
libraries. In my case, this w32compat.h is included while compiling image.c
for example.

Feel free to comment and adapt for the release version.

Fabrice



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

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

[-- Attachment #2: emacs-24-3.diff --]
[-- Type: application/octet-stream, Size: 12862 bytes --]

=== modified file 'build-aux/move-if-change' (properties changed: +x to -x)
=== modified file 'lib-src/emacsclient.c'
--- lib-src/emacsclient.c	2011-10-27 00:59:21 +0000
+++ lib-src/emacsclient.c	2011-11-10 17:40:29 +0000
@@ -1635,7 +1635,9 @@
   /* Send over our environment and current directory. */
   if (!current_frame)
     {
+#ifndef _MSC_VER
       extern char **environ;
+#endif
       int i;
       for (i = 0; environ[i]; i++)
         {

=== modified file 'lib-src/makefile.w32-in'
--- lib-src/makefile.w32-in	2011-07-07 01:32:56 +0000
+++ lib-src/makefile.w32-in	2011-11-08 18:23:01 +0000
@@ -23,7 +23,7 @@
 
 LOCAL_FLAGS	= -DWINDOWSNT -DDOS_NT -DNO_LDAV=1 \
 		  -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../lib \
-		  -I../nt/inc -I../src
+		  -I../nt/inc -I../src $(EMACS_EXTRA_C_FLAGS)
 
 LIBS 		= $(BASE_LIBS) $(ADVAPI32)
 

=== modified file 'lib/strftime.c'
--- lib/strftime.c	2011-03-31 04:24:03 +0000
+++ lib/strftime.c	2011-11-10 17:39:37 +0000
@@ -36,9 +36,14 @@
 #include <ctype.h>
 #include <time.h>
 
+#ifdef _MSC_VER
+#define tzname _tzname
+#else
 #if HAVE_TZNAME && !HAVE_DECL_TZNAME
 extern char *tzname[];
 #endif
+#endif
+
 
 /* Do multibyte processing if multibytes are supported, unless
    multibyte sequences are safe in formats.  Multibyte sequences are

=== modified file 'lisp/bindings.el'
--- lisp/bindings.el	2011-10-08 16:37:46 +0000
+++ lisp/bindings.el	2011-11-10 17:49:35 +0000
@@ -824,13 +824,13 @@
 ;; Define control-digits.
 (let ((i ?0))
   (while (<= i ?9)
-    (define-key global-map (read (format "[?\\C-%c]" i)) 'digit-argument)
+;    (define-key global-map (read (format "[?\\C-%c]" i)) 'digit-argument)
     (setq i (1+ i))))
 (define-key global-map [?\C--] 'negative-argument)
 ;; Define control-meta-digits.
 (let ((i ?0))
   (while (<= i ?9)
-    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
+;    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
     (setq i (1+ i))))
 (define-key global-map [?\C-\M--] 'negative-argument)
 

=== modified file 'nt/config.nt'
--- nt/config.nt	2011-11-05 17:16:01 +0000
+++ nt/config.nt	2011-11-10 17:42:22 +0000
@@ -303,6 +303,10 @@
 /* Define to 1 if you have the `localtime_r' function. */
 #undef HAVE_LOCALTIME_R
 
+/* Define to 1 if you have the declaration of `strtoll', and to 0 if you
+   don't. */
+#define HAVE_DECL_STRTOLL 1
+
 /* Define to 1 if you have the declaration of `strtoull', and to 0 if you
    don't. */
 #define HAVE_DECL_STRTOULL 1
@@ -353,8 +357,8 @@
 /* A va_copy replacement for MSVC.  */
 #ifdef _MSC_VER
 # ifdef _WIN64
-#  ifndef va_copy
-#   error "va_copy is needed, but not defined!"
+#  ifndef va_copy               /* Need to be checked (?) */
+#   define va_copy(d,s) ((d) = (s))
 #  endif
 # else	/* not _WIN64 */
 #  define va_copy(d,s) ((d) = (s))
@@ -429,7 +433,11 @@
 
    See m/template.h for documentation on writing m/MACHINE.h files.  */
 #undef config_machfile
+#ifdef _WIN64
+#include "m/amdx86-64.h"
+#else
 #include "m/intel386.h"
+#endif
 
 /* Define `subprocesses' should be defined if you want to
    have code for asynchronous subprocesses

=== modified file 'nt/configure.bat'
--- nt/configure.bat	2011-05-07 04:00:12 +0000
+++ nt/configure.bat	2011-11-09 15:43:42 +0000
@@ -96,8 +96,8 @@
 set profile=N
 set nocygwin=N
 set COMPILER=
-set usercflags=
-set escusercflags=
+set usercflags=-I../src -I../nt/inc -I../lib -Ic:/source/XEmTeX/source/libs/w32compat -Ic:/source/XEmTeX/source/libs/zlib-1.2.5 -Ic:/source/XEmTeX/source/libs/libpng-1.5.4 -Ic:/source/XEmTeX/source/libs/jpeg-8b -Ic:/source/XEmTeX/source/libs/tiff-3.9.5/libtiff -Ic:/source/XEmTeX/source/libs/giflib-4.1.6/lib -Ic:/source/XEmTeX/source/libs/xpm-3.4k -Ic:/source/XEmTeX/source/libs/xpm-3.4k/lib
+set escusercflags=-I../src -I../nt/inc -I../lib -Ic:/source/XEmTeX/source/libs/w32compat -Ic:/source/XEmTeX/source/libs/zlib-1.2.5 -Ic:/source/XEmTeX/source/libs/libpng-1.5.4 -Ic:/source/XEmTeX/source/libs/jpeg-8b -Ic:/source/XEmTeX/source/libs/tiff-3.9.5/libtiff -Ic:/source/XEmTeX/source/libs/giflib-4.1.6/lib -Ic:/source/XEmTeX/source/libs/xpm-3.4k -Ic:/source/XEmTeX/source/libs/xpm-3.4k/lib
 set docflags=
 set userldflags=
 set escuserldflags=
@@ -536,7 +536,8 @@
 echo The failed program was: >>config.log
 type junk.c >>config.log
 set HAVE_PNG=
-goto :pngDone
+rem goto :pngDone
+goto :end
 
 :havePng
 echo ...PNG header available, building with PNG support.

=== modified file 'nt/emacs.rc'
--- nt/emacs.rc	2011-10-31 02:25:01 +0000
+++ nt/emacs.rc	2011-11-10 02:47:58 +0000
@@ -1,6 +1,10 @@
 Emacs ICON   icons\emacs.ico
 32649 CURSOR icons\hand.cur
+#ifdef WIN64
+1 24 "emacs-x64.manifest"
+#else
 1 24 "emacs.manifest"
+#endif
 
 #ifndef VS_VERSION_INFO
 #define VS_VERSION_INFO 1

=== modified file 'nt/inc/inttypes.h'
--- nt/inc/inttypes.h	2011-05-06 12:09:08 +0000
+++ nt/inc/inttypes.h	2011-11-08 04:33:57 +0000
@@ -24,7 +24,13 @@
 #include_next <inttypes.h>
 #else  /* !__MINGW32__ */
 #include "stdint.h"
+#ifdef _WIN64
 #define strtoumax _strtoui64
+#define strtoimax _strtoi64
+#else
+#define strtoumax strtoul
+#define strtoimax strtol
+#endif
 #endif	/* !__MINGW32__ */
 
 #endif

=== modified file 'nt/inc/stdint.h'
--- nt/inc/stdint.h	2011-11-05 22:33:44 +0000
+++ nt/inc/stdint.h	2011-11-10 01:36:50 +0000
@@ -29,7 +29,9 @@
 
 #ifdef _WIN64
 typedef __int64 intptr_t;
-#define UINT64_MAX 18446744073709551616
+typedef unsigned int uint32_t;
+typedef unsigned __int64 uint64_t;
+#define UINT64_MAX (18446744073709551615i64)
 #define UINT64_MIN 0
 /* "i64" is the non-standard suffix used by MSVC for 64-bit constants.  */
 #define INT64_MAX 9223372036854775807i64
@@ -39,6 +41,8 @@
 #define UINTMAX_MIN UINT64_MIN
 #define INTMAX_MAX INT64_MAX
 #define INTMAX_MIN INT64_MIN
+#define uintmax_t unsigned __int64
+#define intmax_t __int64
 #else
 typedef int intptr_t;
 typedef unsigned int uint32_t;
@@ -51,10 +55,10 @@
 #define UINTMAX_MIN UINT32_MIN
 #define INTMAX_MAX INT32_MAX
 #define INTMAX_MIN INT32_MIN
+#define uintmax_t unsigned long
+#define intmax_t long
 #endif
 
-#define uintmax_t unsigned __int64
-#define intmax_t __int64
 #define PTRDIFF_MAX INTPTR_MAX
 
 #endif	/* !__GNUC__ */

=== modified file 'nt/nmake.defs'
--- nt/nmake.defs	2011-11-05 11:34:56 +0000
+++ nt/nmake.defs	2011-11-09 16:52:19 +0000
@@ -86,7 +86,11 @@
 !    if "$(PROCESSOR_ARCHITECTURE)" == "PPC"
 ARCH		= ppc
 !    else
-!     error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     if "$(PROCESSOR_ARCHITECTURE)" == "AMD64"
+ARCH		= AMD64
+!     else
+!      error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     endif
 !    endif
 !   endif
 !  endif
@@ -164,7 +168,11 @@
 
 # see comments in allocate_heap in w32heap.c before changing any of the
 # -stack, -heap, or -base settings.
+!if "$(ARCH)" == "AMD64"
+TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:x64 $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
+!else
 TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:$(ARCH) $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
+!endif
 
 !ifdef NOOPT
 OBJDIR          = obj
@@ -234,11 +242,24 @@
 ARCH_LDFLAGS	= $(SYS_LDFLAGS)
 
 !else
+!if "$(ARCH)" == "AMD64"
+# These flags are a guess...if they don't work, please send me mail.
+!ifdef NOOPT
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Od -Gd $(DEBUG_FLAG)
+!else
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Oi -Ot -Oy- -Ob2 -GF -Gy -Gd $(DEBUG_FLAG)
+!endif
+ARCH_LDFLAGS	= $(SYS_LDFLAGS) -machine:x64
+
+!else
 !ERROR Unknown architecture type "$(ARCH)".
 !endif
 !endif
 !endif
 !endif
+!endif
 
 LINK_FLAGS	= $(ARCH_LDFLAGS) $(DEBUG_LINK) $(USER_LDFLAGS)
 

=== modified file 'src/lisp.h'
--- src/lisp.h	2011-11-07 17:04:01 +0000
+++ src/lisp.h	2011-11-10 17:24:14 +0000
@@ -163,14 +163,23 @@
 /* First, try and define DECL_ALIGN(type,var) which declares a static
    variable VAR of type TYPE with the added requirement that it be
    TYPEBITS-aligned.  */
+
+#ifndef GCTYPEBITS
+#define GCTYPEBITS 3
+#endif
+
 #ifndef NO_DECL_ALIGN
 # ifndef DECL_ALIGN
 #  if HAVE_ATTRIBUTE_ALIGNED
 #   define DECL_ALIGN(type, var) \
      type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var
 #  elif defined(_MSC_VER)
+#   define ALIGN_GCTYPEBITS 8
+#   if (1 << GCTYPEBITS) != ALIGN_GCTYPEBITS
+#    error ALIGN_GCTYPEBITS is wrong!
+#   endif
 #   define DECL_ALIGN(type, var) \
-     type __declspec(align(1 << GCTYPEBITS)) var
+     type __declspec(align(ALIGN_GCTYPEBITS)) var
 #  else
      /* What directives do other compilers use?  */
 #  endif
@@ -300,10 +309,6 @@
     Lisp_Fwd_Kboard_Obj,	/* Fwd to a Lisp_Object field of kboards.  */
   };
 
-#ifndef GCTYPEBITS
-#define GCTYPEBITS 3
-#endif
-
 /* These values are overridden by the m- file on some machines.  */
 #ifndef VALBITS
 #define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS)

=== modified file 'src/m/amdx86-64.h'
--- src/m/amdx86-64.h	2011-04-19 00:34:42 +0000
+++ src/m/amdx86-64.h	2011-11-08 16:00:11 +0000
@@ -27,9 +27,17 @@
 /* __x86_64 defined automatically.  */
 
 /* Define the type to use.  */
+#ifdef _WIN64
+#define EMACS_INT               __int64
+#define pI			"i64"
+#define EMACS_UINT              unsigned __int64
+#define VIRT_ADDR_VARIES
+#define DATA_START 	get_data_start ()
+#else
 #define EMACS_INT               long
 #define pI			"l"
 #define EMACS_UINT              unsigned long
+#endif
 
 /* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
 #undef DATA_SEG_BITS

=== modified file 'src/makefile.w32-in'
--- src/makefile.w32-in	2011-11-05 22:55:08 +0000
+++ src/makefile.w32-in	2011-11-10 02:16:49 +0000
@@ -177,7 +177,7 @@
 $(TEMACS):      $(TLIB0) $(TLIB1) $(TLIB2) $(TLASTLIB) $(TOBJ) $(TRES) \
 		  ../nt/$(BLD)/addsection.exe $(GNULIB)
 	$(LINK) $(LINK_OUT)$(TEMACS_TMP) $(FULL_LINK_FLAGS) $(TOBJ) $(TRES) $(LIBS)
-	"$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)" EMHEAP 21
+	"$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)" EMHEAP 42
 
 # These omit firstfile.${O}, but there's no documentation in there
 # anyways.

=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h	2011-11-05 16:30:13 +0000
+++ src/s/ms-w32.h	2011-11-10 17:46:07 +0000
@@ -275,11 +275,13 @@
 #define popen     _popen
 #define pclose    _pclose
 #define umask	  _umask
-#define utimbuf	  _utimbuf
+#define snprintf  _snprintf
 #define strdup    _strdup
+#define strtoll   _strtoi64
 #define strupr    _strupr
 #define strnicmp  _strnicmp
 #define stricmp   _stricmp
+/* #define tzname    _tzname */
 #define tzset     _tzset
 
 #if !defined (_MSC_VER) || (_MSC_VER < 1400)
@@ -335,7 +337,7 @@
 #define _WINSOCK_H
 
 /* Defines size_t and alloca ().  */
-#if (defined(_MSC_VER) && defined(emacs)) || defined(USE_CRT_DLL)
+#if (defined(_MSC_VER) && defined(emacs))
 #define malloc e_malloc
 #define free   e_free
 #define realloc e_realloc

=== modified file 'src/w32.c'
--- src/w32.c	2011-11-07 16:42:34 +0000
+++ src/w32.c	2011-11-10 17:46:50 +0000
@@ -1665,10 +1665,10 @@
 
       if (!GetModuleFileName (NULL, modname, MAX_PATH))
 	abort ();
+
       if ((p = strrchr (modname, '\\')) == NULL)
 	abort ();
       *p = 0;
-
       if ((p = strrchr (modname, '\\')) && xstrcasecmp (p, "\\bin") == 0)
 	{
 	  char buf[SET_ENV_BUF_SIZE];
@@ -1685,7 +1685,8 @@
       /* FIXME: should use substring of get_emacs_configuration ().
 	 But I don't think the Windows build supports alpha, mips etc
          anymore, so have taken the easy option for now.  */
-      else if (p && xstrcasecmp (p, "\\i386") == 0)
+      else if (p && (xstrcasecmp (p, "\\i386") == 0
+                     || xstrcasecmp (p, "\\AMD64") == 0))
 	{
 	  *p = 0;
 	  p = strrchr (modname, '\\');

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2011-11-08 20:05:27 +0000
+++ src/xdisp.c	2011-11-10 17:20:07 +0000
@@ -1086,7 +1086,11 @@
    area AREA of window W.  AREA < 0 means return the right edge of the
    whole window, to the left of the right fringe of W.  */
 
+#ifdef _MSC_VER
 int
+#else
+inline int
+#endif
 window_box_right_offset (struct window *w, int area)
 {
   return window_box_left_offset (w, area) + window_box_width (w, area);
@@ -1116,7 +1120,11 @@
    area AREA of window W.  AREA < 0 means return the right edge of the
    whole window, to the left of the right fringe of W.  */
 
+#ifdef _MSC_VER
 int
+#else
+inline int
+#endif
 window_box_right (struct window *w, int area)
 {
   return window_box_left (w, area) + window_box_width (w, area);


[-- Attachment #3: emacs-x64.manifest --]
[-- Type: application/octet-stream, Size: 821 bytes --]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0" processorArchitecture="AMD64"
                        publicKeyToken="6595b64144ccf1df"
                        language="*"/>
    </dependentAssembly>
  </dependency>
  <assemblyIdentity version="1.0.0.0" processorArchitecture="AMD64"
		    name="emacs" type="win32"/>
  <description>GNU Emacs</description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

[-- Attachment #4: w32compat.h --]
[-- Type: text/x-chdr, Size: 6010 bytes --]


#ifndef _W32COMPAT_H_
#define _W32COMPAT_H_ 1

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <io.h>
#include <conio.h>
#include <direct.h>
#include <malloc.h>
#include <../include/process.h>
#include <time.h>
#include <sys/types.h>
#define dev_t _dev_t
#define fstat _fstat
#define chmod _chmod
#include <sys/stat.h>
#include <../include/sys/time.h>
#include <sys/utime.h>
#include <sys/locking.h>

#include <signal.h>
typedef unsigned int sigset_t;

typedef unsigned int ssize_t;

#ifndef _WIN64
typedef unsigned short mode_t;
#endif

#if 0
struct timezone
  {
    int	tz_minuteswest;	/* minutes west of Greenwich */
    int	tz_dsttime;	/* type of dst correction */
  };
#endif

void gettimeofday (struct timeval *, struct timezone *);
struct tm *gmtime_r (time_t const * __restrict, struct tm * __restrict);
struct tm *localtime_r (time_t const * __restrict, struct tm * __restrict);

#include <string.h>
#include <mbstring.h>

#define inline __inline

#ifndef O_RDONLY
#define O_RDONLY _O_RDONLY
#endif
#ifndef O_WRONLY
#define O_WRONLY _O_WRONLY
#endif
#ifndef O_RDWR
#define O_RDWR _O_RDWR
#endif
#ifndef O_APPEND
#define O_APPEND _O_APPEND
#endif
#ifndef O_CREAT
#define O_CREAT _O_CREAT
#endif
#ifndef O_TRUNC
#define O_TRUNC _O_TRUNC
#endif
#ifndef O_EXCL
#define O_EXCL _O_EXCL
#endif
#ifndef O_TEXT
#define O_TEXT _O_TEXT
#endif
#ifndef O_BINARY
#define O_BINARY _O_BINARY
#endif
#ifndef O_RAW
#define O_RAW           _O_BINARY
#endif
#ifndef O_TEMPORARY
#define O_TEMPORARY     _O_TEMPORARY
#endif
#ifndef O_NOINHERIT
#define O_NOINHERIT     _O_NOINHERIT
#endif
#ifndef O_SEQUENTIAL
#define O_SEQUENTIAL    _O_SEQUENTIAL
#endif
#ifndef O_RANDOM
#define O_RANDOM        _O_RANDOM
#endif

#define alloca _alloca
#define stricmp _stricmp

#define access _access
#define chmod _chmod
#define chsize _chsize
#define close _close
#define creat _creat
#define dup _dup
#define dup2 _dup2
#if 0
/* This one conflicts with texk/web2/lib/eofeoln.c */
#define eof _eof
#endif
#define filelength _filelength
#define isatty _isatty
#define locking _locking
#define lseek _lseek
#define mktemp _mktemp
#define open _open
#define read _read
#define setmode _setmode
#define sopen _sopen
#define tell _tell
#define umask _umask
#define unlink _unlink
#define write _write

#define cgets _cgets
#define cprintf _cprintf
#define cputs _cputs
#define cscanf _cscanf
#define inp _inp
#define inpw _inpw
#define getch _getch
#define getche _getche
#define kbhit _kbhit
#define outp _outp
#define outpw _outpw
#define putch _putch
#define ungetch _ungetch

#define chdir _chdir
#define getcwd _getcwd
#define mkdir _mkdir
#define rmdir _rmdir

#define CLK_TCK  CLOCKS_PER_SEC

#if _MSC_VER <= 1310
#define timezone _timezone
#endif
#define daylight _daylight
#define tzname _tzname
#define tzset _tzset

#define P_WAIT          _P_WAIT
#define P_NOWAIT        _P_NOWAIT
#define P_OVERLAY       _P_OVERLAY
#define OLD_P_OVERLAY   _OLD_P_OVERLAY
#define P_NOWAITO       _P_NOWAITO
#define P_DETACH        _P_DETACH
#define WAIT_CHILD      _WAIT_CHILD
#define WAIT_GRANDCHILD _WAIT_GRANDCHILD

#define cwait _cwait
#define execl _execl
#define execle _execle
#define execlp _execlp
#define execlpe _execlpe
#define execv _execv
#define execve _execve
#define execvp _execvp
#define execvpe _execvpe
#define spawnl _spawnl
#define spawnle _spawnle
#define spawnlp _spawnlp
#define spawnlpe _spawnlpe
#define spawnv _spawnv
#define spawnve _spawnve
#define spawnvp _spawnvp
#define spawnvpe _spawnvpe

#define getpid _getpid

#define P_tmpdir  _P_tmpdir
#define SYS_OPEN  _SYS_OPEN

#define fcloseall _fcloseall
#define fdopen _fdopen
#define fgetchar _fgetchar
#define fileno _fileno
#define flushall _flushall
#define fputchar _fputchar
#define getw _getw
#define putw _putw
#define rmtmp _rmtmp
#define tempnam _tempnam
#define unlink _unlink

#define sys_errlist _sys_errlist
#define sys_nerr    _sys_nerr
#define environ     _environ

#define onexit_t _onexit_t

#define ecvt _ecvt
#define fcvt _fcvt
#define gcvt _gcvt
#define itoa _itoa
#define ltoa _ltoa
#define onexit _onexit
#define putenv _putenv
#define swab _swab
#define ultoa _ultoa

#ifndef S_IFMT
#define S_IFMT _S_IFMT
#endif
#ifndef S_IFDIR
#define S_IFDIR _S_IFDIR
#endif
#ifndef S_IFCHR
#define S_IFCHR _S_IFCHR
#endif
#ifndef S_IFIFO
#define S_IFIFO _S_IFIFO
#endif
#ifndef S_IFREG
#define S_IFREG _S_IFREG
#endif
#ifndef S_IREAD
#define S_IREAD _S_IREAD
#endif
#ifndef S_IWRITE
#define S_IWRITE _S_IWRITE
#endif
#ifndef S_IEXEC
#define S_IEXEC  _S_IEXEC
#endif
#ifndef S_IXUSR
#define S_IXUSR _S_IEXEC
#endif
#ifndef S_IXGRP
#define S_IXGRP _S_IEXEC
#endif
#ifndef S_IXOTH
#define S_IXOTH _S_IEXEC
#endif
#ifndef S_IRUSR
#define S_IRUSR _S_IREAD
#endif
#ifndef S_IRGRP
#define S_IRGRP _S_IREAD
#endif
#ifndef S_IROTH
#define S_IROTH _S_IREAD
#endif
#ifndef S_IWUSR
#define S_IWUSR _S_IWRITE
#endif
#ifndef S_IWGRP
#define S_IWGRP _S_IWRITE
#endif
#ifndef S_IWOTH
#define S_IWOTH _S_IWRITE
#endif

#if 0
#define stat _stat64i32
#endif

typedef long off_t;

/* from string.h */
#define memccpy _memccpy
#define memicmp _memicmp
#define strcmpi _strcmpi
#define stricmp _stricmp
#define strdup _strdup
#define strlwr _strlwr
#define strnicmp _strnicmp
#define strnset _strnset
#define strrev _strrev
#define strset _strset
#define strupr _strupr
#define wcsdup _wcsdup

#define isascii __isascii
#define toascii __toascii
#define iscsymf __iscsymf
#define iscsym  __iscsym

#define timeb __timeb32

#define ftime _ftime

#define utimbuf _utimbuf
#define utime _utime

#define locking _locking
#define LK_LOCK _LK_LOCK
#define LK_NBLCK _LK_NBLCK
#define LK_NBRLCK _LK_NBRLCK
#define LK_RLCK _LK_RLCK
#define LK_UNLCK _LK_UNLCK

#endif

bug#9960: Compiling Emacs trunk with MSVC

[Lennart Borgman]

On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
<fabrice.popineau@supelec.fr> wrote:
>
> - the 64 bits version compiles and dumps, but fails to bootstrap (seems to
> be looping inside elisp code).
> Is there any interest in having a 64bits windows emacs ?

I think it would be good with a 64 bit windows emacs. I see some
problem when I am running the 32 bit emacs in w7 64-bit. (However that
is my own version, the version I am very dependant on now and that I
have no time to merge into the core emacs).

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
<fabrice.popineau@supelec.fr> wrote:

> Is there any interest in having a 64bits windows emacs ?

Yes.

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Thu, Nov 10, 2011 at 21:28, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I see some
> problem when I am running the 32 bit emacs in w7 64-bit. (However that
> is my own version, the version I am very dependant on now and that I
> have no time to merge into the core emacs).

I run stock Emacs, compiled from the trunk, on W7 64-bit and I have
not seen any problem. What kind of problems do you see?

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Thu, 10 Nov 2011 20:56:11 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> Sure. feel free to adapt on the basis of the attached patch.
> Status is :
> - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able to
> boostrap itself.

Great news, thanks.

> Is there any interest in having a 64bits windows emacs ?

Yes, though if the changes are significant, they will probably not
make it into Emacs 24.1.  Plus, I think you will need to sign legal
papers to contribute more than what you already have.  (I can
currently find on file your assignment only to Gnus.)

> I have added two other files : a 64bits manifest for emacs.exe and a
> w32compat.h header file that is needed to compile the above mentioned
> libraries. In my case, this w32compat.h is included while compiling image.c
> for example.

Is this for a 64-bit build, or is this needed for a 32-bit build as
well?  If for a 32-bit built, then what exactly are the problems with
image.c that requires w32compat.h?

> +#ifndef _MSC_VER
>        extern char **environ;
> +#endif

Which MSVC header has the necessary declaration, and what is that
declaration?

> --- lib/strftime.c	2011-03-31 04:24:03 +0000
> +++ lib/strftime.c	2011-11-10 17:39:37 +0000
> @@ -36,9 +36,14 @@
>  #include <ctype.h>
>  #include <time.h>
>  
> +#ifdef _MSC_VER
> +#define tzname _tzname
> +#else
>  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
>  extern char *tzname[];

Can we instead modify the #define on src/s/ms-w32.h so as to include
versions of MSVC above 1400?  Or does that not work for some reason?

I'd like to avoid changing source files in lib/, since they are
imported from gnulib.

> --- lisp/bindings.el	2011-10-08 16:37:46 +0000
> +++ lisp/bindings.el	2011-11-10 17:49:35 +0000
> @@ -824,13 +824,13 @@
>  ;; Define control-digits.
>  (let ((i ?0))
>    (while (<= i ?9)
> -    (define-key global-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> +;    (define-key global-map (read (format "[?\\C-%c]" i)) 'digit-argument)
>      (setq i (1+ i))))
>  (define-key global-map [?\C--] 'negative-argument)
>  ;; Define control-meta-digits.
>  (let ((i ?0))
>    (while (<= i ?9)
> -    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> +;    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
>      (setq i (1+ i))))
>  (define-key global-map [?\C-\M--] 'negative-argument)

Why is this part needed?

> === modified file 'src/makefile.w32-in'
> --- src/makefile.w32-in	2011-11-05 22:55:08 +0000
> +++ src/makefile.w32-in	2011-11-10 02:16:49 +0000
> @@ -177,7 +177,7 @@
>  $(TEMACS):      $(TLIB0) $(TLIB1) $(TLIB2) $(TLASTLIB) $(TOBJ) $(TRES) \
>  		  ../nt/$(BLD)/addsection.exe $(GNULIB)
>  	$(LINK) $(LINK_OUT)$(TEMACS_TMP) $(FULL_LINK_FLAGS) $(TOBJ) $(TRES) $(LIBS)
> -	"$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)" EMHEAP 21
> +	"$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)" EMHEAP 42

Is such a large heap really needed for a 32-bit MSVC build?  Or is it
for the 64-bit build?

> -#if (defined(_MSC_VER) && defined(emacs)) || defined(USE_CRT_DLL)
> +#if (defined(_MSC_VER) && defined(emacs))
>  #define malloc e_malloc
>  #define free   e_free
>  #define realloc e_realloc

What was the problem that required this change?

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> Yes, though if the changes are significant, they will probably not
> make it into Emacs 24.1.  Plus, I think you will need to sign legal
> papers to contribute more than what you already have.  (I can
> currently find on file your assignment only to Gnus.)
>
>
Ok, I'll do it if needed. Albeit it is almost only a matter of configuring
the right defines.


>  > I have added two other files : a 64bits manifest for emacs.exe and a
> > w32compat.h header file that is needed to compile the above mentioned
> > libraries. In my case, this w32compat.h is included while compiling
> image.c
> > for example.
>
> Is this for a 64-bit build, or is this needed for a 32-bit build as
> well?  If for a 32-bit built, then what exactly are the problems with
> image.c that requires w32compat.h?
>
>
The problem is that image.c includes png.h (for example) and png.h
may compile out of the box ... or not. In my case, I always try to compile
all the libraries with the same set of defines and options. So I included
this
file for completeness.

I have both the  7.1 MS SDK and VS2010 installed on my machine.
Using this w32compat.h plus the emacs/nt/inc and emacs/lib,
I was able to compile all the libraries
(32bits and 64 bits versions). And emacs too of course.



> > +#ifndef _MSC_VER
> >        extern char **environ;
> > +#endif
>
> Which MSVC header has the necessary declaration, and what is that
> declaration?
>

#include <stdlib.h>
is enough.

Extract :

#if !defined(_M_CEE_PURE)
#ifdef  _POSIX_
extern char ** environ;             /* pointer to environment table */
#else
_CRTIMP extern char ** _environ;    /* pointer to environment table */
_CRTIMP extern wchar_t ** _wenviron;    /* pointer to wide environment
table */
#endif  /* _POSIX_ */
#else

_CRTIMP char*** __cdecl __p__environ(void);
_CRTIMP wchar_t*** __cdecl __p__wenviron(void);
_CRT_INSECURE_DEPRECATE_GLOBALS(_get_pgmptr) _CRTIMP char** __cdecl
__p__pgmptr(void);
_CRT_INSECURE_DEPRECATE_GLOBALS(_get_wpgmptr) _CRTIMP wchar_t** __cdecl
__p__wpgmptr(void);

#define _environ   (*__p__environ())
#define _wenviron  (*__p__wenviron())
#define _pgmptr    (*__p__pgmptr())
#define _wpgmptr   (*__p__wpgmptr())

#endif /* !defined(_M_CEE_PURE) */


> > --- lib/strftime.c    2011-03-31 04:24:03 +0000
> > +++ lib/strftime.c    2011-11-10 17:39:37 +0000
> > @@ -36,9 +36,14 @@
> >  #include <ctype.h>
> >  #include <time.h>
> >
> > +#ifdef _MSC_VER
> > +#define tzname _tzname
> > +#else
> >  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
> >  extern char *tzname[];
>
> Can we instead modify the #define on src/s/ms-w32.h so as to include
> versions of MSVC above 1400?  Or does that not work for some reason?


Ok, I removed the restriction on MSVC version below 1400 and that is
compiling.


> > --- lisp/bindings.el  2011-10-08 16:37:46 +0000

> +++ lisp/bindings.el  2011-11-10 17:49:35 +0000
> > @@ -824,13 +824,13 @@
> >  ;; Define control-digits.
> >  (let ((i ?0))
> >    (while (<= i ?9)
> > -    (define-key global-map (read (format "[?\\C-%c]" i))
> 'digit-argument)
> > +;    (define-key global-map (read (format "[?\\C-%c]" i))
> 'digit-argument)
> >      (setq i (1+ i))))
> >  (define-key global-map [?\C--] 'negative-argument)
> >  ;; Define control-meta-digits.
> >  (let ((i ?0))
> >    (while (<= i ?9)
> > -    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> > +;    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> >      (setq i (1+ i))))
> >  (define-key global-map [?\C-\M--] 'negative-argument)
>
> Why is this part needed?
>

I would like to know. I get an error when bootstrapping at these lines :
invalid read syntax.
If someone has a suggestion on how to investigate it, I'd like to hear it:

Loading bindings (source)...
Invalid read syntax: "?"
NMAKE : fatal error U1077:
'C:\Source\XEmTeX\mirror\emacs\src/obj-spd/i386/temacs.exe' : return code
'0xffffffff'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\Bin\nmake.exe"' : return code '0x2'
Stop.

It is failing only while bootstrapping, not during  the regular build.


> === modified file 'src/makefile.w32-in'
> > --- src/makefile.w32-in       2011-11-05 22:55:08 +0000
> > +++ src/makefile.w32-in       2011-11-10 02:16:49 +0000
> > @@ -177,7 +177,7 @@
> >  $(TEMACS):      $(TLIB0) $(TLIB1) $(TLIB2) $(TLASTLIB) $(TOBJ) $(TRES) \
> >                 ../nt/$(BLD)/addsection.exe $(GNULIB)
> >       $(LINK) $(LINK_OUT)$(TEMACS_TMP) $(FULL_LINK_FLAGS) $(TOBJ)
> $(TRES) $(LIBS)
> > -     "$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)"
> EMHEAP 21
> > +     "$(THISDIR)/../nt/$(BLD)/addsection" "$(TEMACS_TMP)" "$(TEMACS)"
> EMHEAP 42
>
> Is such a large heap really needed for a 32-bit MSVC build?  Or is it
> for the 64-bit build?


I tried to double it for the 64 bits build in the hope it will let me go a
bit further.
Maybe that size is not needed even in this case. So forget it for the
moment.

Also, it seems that it is possible to declare segments using #pragma
and that they can even be resized using the editbin tool (available with
the sdk). That may make addsection useless, and wrt to a 64bits build,
I would be more confident in using the sdk tools if possible.

I'll try to remove the use of addsection if possible. Well, if someone has
a good reason
for which it is not possible, let me know.



> -#if (defined(_MSC_VER) && defined(emacs)) || defined(USE_CRT_DLL)
> > +#if (defined(_MSC_VER) && defined(emacs))
> >  #define malloc e_malloc
> >  #define free   e_free
> >  #define realloc e_realloc
>
> What was the problem that required this change?


Linking all other programs except emacs.
For the other programs, you surely don't want to define malloc to be
e_malloc  ?

Being able to link against libc or msvcrt is confusing.
Wouldn't it be better if only MSVCRT was supported ?
Does the build work with the static libc ?

Best regards,

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Fri, 11 Nov 2011 20:28:21 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> > +++ lisp/bindings.el  2011-11-10 17:49:35 +0000
> > > @@ -824,13 +824,13 @@
> > >  ;; Define control-digits.
> > >  (let ((i ?0))
> > >    (while (<= i ?9)
> > > -    (define-key global-map (read (format "[?\\C-%c]" i))
> > 'digit-argument)
> > > +;    (define-key global-map (read (format "[?\\C-%c]" i))
> > 'digit-argument)
> > >      (setq i (1+ i))))
> > >  (define-key global-map [?\C--] 'negative-argument)
> > >  ;; Define control-meta-digits.
> > >  (let ((i ?0))
> > >    (while (<= i ?9)
> > > -    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> > > +;    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> > >      (setq i (1+ i))))
> > >  (define-key global-map [?\C-\M--] 'negative-argument)
> >
> > Why is this part needed?
> >
> 
> I would like to know. I get an error when bootstrapping at these lines :
> invalid read syntax.

I'll have a look.

> Also, it seems that it is possible to declare segments using #pragma
> and that they can even be resized using the editbin tool (available with
> the sdk). That may make addsection useless, and wrt to a 64bits build,
> I would be more confident in using the sdk tools if possible.
> 
> I'll try to remove the use of addsection if possible. Well, if someone has
> a good reason for which it is not possible, let me know.

Most people build Emacs using MinGW, where editbin is not available.

But we could tweak gmake.defs and nmake.defs such that MSVC builds do
use editbin.

> Being able to link against libc or msvcrt is confusing.
> Wouldn't it be better if only MSVCRT was supported ?
> Does the build work with the static libc ?

Sorry, I don't know enough about the various libraries provided by MS
to answer that.  In general, we must support a build against libraries
that are part of the OS, we cannot rely on users having the SDK or the
Studio installation.  So linking against libraries that are only
distributed with VS must be an option.  Even using vcredist packages
as a prerequisite would be a nuisance.

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> > I'll try to remove the use of addsection if possible. Well, if someone
> has
> > a good reason for which it is not possible, let me know.
>
> Most people build Emacs using MinGW, where editbin is not available.
>
> But we could tweak gmake.defs and nmake.defs such that MSVC builds do
> use editbin.


Ok. Good point. At first, when I tried the 64bits build, the executable
wouldn't run.
I was afraid that it was because of the addsection tweak. Eventually, it
turned out
that it was the emacs.manifest file that specified the .exe as a 32bits
executable.
Hence the reason for the 64bits manifest. So removing addsection is not a
priority
at all.


>  > Being able to link against libc or msvcrt is confusing.
> > Wouldn't it be better if only MSVCRT was supported ?
> > Does the build work with the static libc ?
>
> Sorry, I don't know enough about the various libraries provided by MS
> to answer that.  In general, we must support a build against libraries
> that are part of the OS, we cannot rely on users having the SDK or the
> Studio installation.  So linking against libraries that are only
> distributed with VS must be an option.  Even using vcredist packages
> as a prerequisite would be a nuisance.
>

Even better point. MSVCRT.dll is provided with the OS and some parts of it
are linked against
this dll. However, Visual Studio provides msvcrt80.dll, msvcrt90.dll,
msvcrt100.dll (one for each
new release of VS) and they need to be redistributed with the program. It
makes sense if you
are building an installer (it is even easy).

So, I have rebuilt emacs with the static libc. It is working too,
except for nt/cmdproxy that required :

=== modified file 'nt/cmdproxy.c'
--- nt/cmdproxy.c       2011-04-27 04:19:15 +0000
+++ nt/cmdproxy.c       2011-11-11 20:41:37 +0000
@@ -46,6 +46,8 @@
 #define stdout GetStdHandle (STD_OUTPUT_HANDLE)
 #define stderr GetStdHandle (STD_ERROR_HANDLE)

+#ifndef _MSC_VER
+
 int
 vfprintf (HANDLE hnd, const char * msg, va_list args)
 {
@@ -81,6 +83,7 @@

   return rc;
 }
+#endif /* _MSC_VER */

 void
 fail (const char * msg, ...)

This patch is ok for both the static libc and the dynamic one.
Without it, link complains that printf is redefined in the case of the
static libc.
By the way, I don't know how the MingW libraries are organized, but defining
printf and co to spare some functions when linking ... it doesn't work with
cl and
libc/msvcrt because other libc functions are used too : strncpy, strdup etc.
So it is not possible to avoid linking against libc (?).

-- 
Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Fri, 11 Nov 2011 22:55:54 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> >  > Being able to link against libc or msvcrt is confusing.
> > > Wouldn't it be better if only MSVCRT was supported ?
> > > Does the build work with the static libc ?
> >
> > Sorry, I don't know enough about the various libraries provided by MS
> > to answer that.  In general, we must support a build against libraries
> > that are part of the OS, we cannot rely on users having the SDK or the
> > Studio installation.  So linking against libraries that are only
> > distributed with VS must be an option.  Even using vcredist packages
> > as a prerequisite would be a nuisance.
> >
> 
> Even better point. MSVCRT.dll is provided with the OS and some parts
> of it are linked against this dll. However, Visual Studio provides
> msvcrt80.dll, msvcrt90.dll, msvcrt100.dll (one for each new release
> of VS) and they need to be redistributed with the program. It makes
> sense if you are building an installer (it is even easy).
> 
> So, I have rebuilt emacs with the static libc. It is working too,
> except for nt/cmdproxy that required :
> 
> === modified file 'nt/cmdproxy.c'
> --- nt/cmdproxy.c       2011-04-27 04:19:15 +0000
> +++ nt/cmdproxy.c       2011-11-11 20:41:37 +0000
> @@ -46,6 +46,8 @@
>  #define stdout GetStdHandle (STD_OUTPUT_HANDLE)
>  #define stderr GetStdHandle (STD_ERROR_HANDLE)
> 
> +#ifndef _MSC_VER
> +
>  int
>  vfprintf (HANDLE hnd, const char * msg, va_list args)
>  {
> @@ -81,6 +83,7 @@
> 
>    return rc;
>  }
> +#endif /* _MSC_VER */
> 
>  void
>  fail (const char * msg, ...)
> 
> This patch is ok for both the static libc and the dynamic one.
> Without it, link complains that printf is redefined in the case of
> the static libc.  By the way, I don't know how the MingW libraries
> are organized, but defining printf and co to spare some functions
> when linking ... it doesn't work with cl and libc/msvcrt because
> other libc functions are used too : strncpy, strdup etc.  So it is
> not possible to avoid linking against libc (?).

You will have to bear with me, as I cannot easily grok what you are
trying to explain.  E.g., what is "the static libc"?

To answer your question about MinGW, here are the default libraries
that the linker is instructed to scan when linking a program:

 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

Out of these, libgcc.a is a static library that comes with GCC,
libmingw32.a and libmingwex.a are static libraries specific to MinGW
(the former includes the startup modules like CRTglob, the latter math
functions and a few MinGW replacements for missing or buggy functions
from the MS runtime), libmoldname.a is a static library of stubs that
provide FOO where MS runtime only has _FOO (like _access, _dup2,
etc.), and all the rest are Windows dynamic libraries; MinGW just
supplies import libs for them.  I hope this answers your question
about the organization of the MinGW libraries.  IIUC, the above means
MinGW does not have any "static libc", so it must link against the
dynamic libraries that constitute the MS runtime.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Fri, 11 Nov 2011 20:28:21 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> > +++ lisp/bindings.el  2011-11-10 17:49:35 +0000
> > > @@ -824,13 +824,13 @@
> > >  ;; Define control-digits.
> > >  (let ((i ?0))
> > >    (while (<= i ?9)
> > > -    (define-key global-map (read (format "[?\\C-%c]" i))
> > 'digit-argument)
> > > +;    (define-key global-map (read (format "[?\\C-%c]" i))
> > 'digit-argument)
> > >      (setq i (1+ i))))
> > >  (define-key global-map [?\C--] 'negative-argument)
> > >  ;; Define control-meta-digits.
> > >  (let ((i ?0))
> > >    (while (<= i ?9)
> > > -    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> > > +;    (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument)
> > >      (setq i (1+ i))))
> > >  (define-key global-map [?\C-\M--] 'negative-argument)
> >
> > Why is this part needed?
> >
> 
> I would like to know. I get an error when bootstrapping at these lines :
> invalid read syntax.
> If someone has a suggestion on how to investigate it, I'd like to hear it:
> 
> Loading bindings (source)...
> Invalid read syntax: "?"
> NMAKE : fatal error U1077:
> 'C:\Source\XEmTeX\mirror\emacs\src/obj-spd/i386/temacs.exe' : return code
> '0xffffffff'
> Stop.
> NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\Bin\nmake.exe"' : return code '0x2'
> Stop.

This error comes from the following fragment in lread.c:read1

    case '?':
      {
	int modifiers;
	int next_char;
	int ok;

	c = READCHAR;
	if (c < 0)
	  end_of_file_error ();

	/* Accept `single space' syntax like (list ? x) where the
	   whitespace character is SPC or TAB.
	   Other literal whitespace like NL, CR, and FF are not accepted,
	   as there are well-established escape sequences for these.  */
	if (c == ' ' || c == '\t')
	  return make_number (c);

	if (c == '\\')
	  c = read_escape (readcharfun, 0);
	modifiers = c & CHAR_MODIFIER_MASK;
	c &= ~CHAR_MODIFIER_MASK;
	if (CHAR_BYTE8_P (c))
	  c = CHAR_TO_BYTE8 (c);
	c |= modifiers;

	next_char = READCHAR;
	ok = (next_char <= 040
	      || (next_char < 0200
		  && strchr ("\"';()[]#?`,.", next_char) != NULL));
	UNREAD (next_char);
	if (ok)
	  return make_number (c);

	invalid_syntax ("?");  <<<<<<<<<<<<<<<<<<
      }

Can you step through this in a debugger and see what character is seen
in next_char at the end of this snippet, and what value is in `c' at
that point, when it fails?  The function read_escape called by this
fragment could also be of interest.

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> > So, I have rebuilt emacs with the static libc. It is working too,
> > except for nt/cmdproxy that required :
> >
> > === modified file 'nt/cmdproxy.c'
> > --- nt/cmdproxy.c       2011-04-27 04:19:15 +0000
> > +++ nt/cmdproxy.c       2011-11-11 20:41:37 +0000
> > @@ -46,6 +46,8 @@
> >  #define stdout GetStdHandle (STD_OUTPUT_HANDLE)
> >  #define stderr GetStdHandle (STD_ERROR_HANDLE)
> >
> > +#ifndef _MSC_VER
> > +
> >  int
> >  vfprintf (HANDLE hnd, const char * msg, va_list args)
> >  {
> > @@ -81,6 +83,7 @@
> >
> >    return rc;
> >  }
> > +#endif /* _MSC_VER */
> >
> >  void
> >  fail (const char * msg, ...)
> >
> > This patch is ok for both the static libc and the dynamic one.
> > Without it, link complains that printf is redefined in the case of
> > the static libc.  By the way, I don't know how the MingW libraries
> > are organized, but defining printf and co to spare some functions
> > when linking ... it doesn't work with cl and libc/msvcrt because
> > other libc functions are used too : strncpy, strdup etc.  So it is
> > not possible to avoid linking against libc (?).
>
> You will have to bear with me, as I cannot easily grok what you are
> trying to explain.  E.g., what is "the static libc"?


There are two MS C libraries you can link with :
- libc is a static library,
- msvcrt is a dll

http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.100).aspx

The main difference between both is that in the event you compile your
program in several modules, and each of these modules need a C library, if
you use msvcrt, then internal variables of the C library are shared amond
the modules, whereas each module gets its own C library internal state if
you use the static libc. (May be relevant for functions like strtok for
example).

Also, to complete what I wrote previously about installation and
redistributables.
It is perfectly possible to compile a foo.exe program and link it with the
current release
of msvcrt (say msvcrt100.dll) and pack this library in the very same
directory
foo.exe is located. You can zip them together and there is nothing to
install.
Your foo.exe program will be dynamically linked with the dll that are
located
in the same directory, before looking anywhere else.



To answer your question about MinGW, here are the default libraries
> that the linker is instructed to scan when linking a program:
>
>  -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
>  -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
>
> Out of these, libgcc.a is a static library that comes with GCC,
> libmingw32.a and libmingwex.a are static libraries specific to MinGW
> (the former includes the startup modules like CRTglob, the latter math
> functions and a few MinGW replacements for missing or buggy functions
> from the MS runtime), libmoldname.a is a static library of stubs that
> provide FOO where MS runtime only has _FOO (like _access, _dup2,
> etc.), and all the rest are Windows dynamic libraries; MinGW just
> supplies import libs for them.  I hope this answers your question
> about the organization of the MinGW libraries.  IIUC, the above means
> MinGW does not have any "static libc", so it must link against the
> dynamic libraries that constitute the MS runtime.
>

Ok, thanks for this detailed explanation.
So it seems that MINGW compiled programs are linked with the MS msvcrt.dll ?
But then, you would need to provide msvcrt.dll together with your binaries ?


Anyway, in the case of cmdproxy, the source code states that :

/* We don't want to include stdio.h because we are already duplicating
   lots of it here */
extern int _snprintf (char *buffer, size_t count, const char *format, ...);

/*******  Mock C library routines  *********************************/

/* These routines are used primarily to minimize the executable size.  */

I don't see exactly how to minimze executable size except by not linking
with any C library. It would be possible to replace the other string
functions
used in cmdproxy.c by Win32 functions and remove the C library from the
needed resources.
But that is not currently what's done.
So all in all, it is as easy to use the C library printf functions,
especially given the fact that
they conflict when I link against the static libc.
(Not sure why they don't when linking with msvcrt, I bet it is because of
an underscore again).

Greetings,

-- 
Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Óscar Fuentes]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

[snip]

> Also, to complete what I wrote previously about installation and
> redistributables.
> It is perfectly possible to compile a foo.exe program and link it with the
> current release
> of msvcrt (say msvcrt100.dll) and pack this library in the very same
> directory
> foo.exe is located. You can zip them together and there is nothing to
> install.
> Your foo.exe program will be dynamically linked with the dll that are
> located
> in the same directory, before looking anywhere else.

I don't think that distributing msvcrt100.dll (or any proprietary
binary) with a GNU binary is acceptable. But I'm not 100% sure, you'll
better check in emacs-devel.

[snip]

> So it seems that MINGW compiled programs are linked with the MS
> msvcrt.dll ?

By default, yes.

> But then, you would need to provide msvcrt.dll together with your
> binaries ?

Not really. msvcrt.dll is distributed with the OS since Windows 98,
IIRC. The Windows 95 users probably have it installed as well, because
so much software depends on it.

[snip]

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/10/2011 12:56 PM, Fabrice Popineau wrote:

> Status is :
> - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able
> to boostrap itself.
> - the 64 bits version compiles and dumps, but fails to bootstrap (seems
> to be looping inside elisp code).

On a clean checkout or after make maintainer-clean `getopt.h' needs to 
be regenerated. In order for this to work with nmake I needed to make 
the following change:

=== modified file 'lib/makefile.w32-in'
--- lib/makefile.w32-in	2011-11-05 11:34:56 +0000
+++ lib/makefile.w32-in	2011-11-06 13:34:03 +0000
@@ -212,7 +212,7 @@

  HAVE_GETOPT_H = HAVE_GETOPT_H
  INCLUDE_NEXT = include_next
-PRAGMA_SYSTEM_HEADER = \#pragma GCC system_header
+PRAGMA_SYSTEM_HEADER = ^#pragma GCC system_header
  PRAGMA_COLUMNS =
  NEXT_GETOPT_H = <getopt.h>
  ARG_NONNULL_H = ../build-aux/snippet/arg-nonnull.h

This is not meant as a permanent fix, but just an example of what is 
necessary to make it work with nmake.

See:
http://msdn.microsoft.com/en-us/library/f8txf85h%28v=vs.80%29.aspx

Should we define an ESCAPE_SPECIAL_CHAR variable in 
nmake.defs/gmake.defs to handle this or is there a way to make the 
platform specific decision in the makefile.w32-in without too much 
duplication?

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> Can you step through this in a debugger and see what character is seen
> in next_char at the end of this snippet, and what value is in `c' at
> that point, when it fails?  The function read_escape called by this
> fragment could also be of interest.
>

Something seems to be messed up in the read_escape function :
it should read the string "[?\\C-0]"
it reads the 'C' and the '-', then it returns the char '0' + ctrl_modifier,
and back in read1, the next char read is '0' again.
Which means that in read1 at the failure point,
next_char = 0x00000030
and c = 0x04000030

I tried to step inside read_escape, but not sure what's going wrong here.

Greetings,

-- 
Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Sat, 12 Nov 2011 10:10:34 -0700
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: Eli Zaretskii <eliz@gnu.org>, 9960@debbugs.gnu.org
> 
> On a clean checkout or after make maintainer-clean `getopt.h' needs to 
> be regenerated. In order for this to work with nmake I needed to make 
> the following change:
> 
> === modified file 'lib/makefile.w32-in'
> --- lib/makefile.w32-in	2011-11-05 11:34:56 +0000
> +++ lib/makefile.w32-in	2011-11-06 13:34:03 +0000
> @@ -212,7 +212,7 @@
> 
>   HAVE_GETOPT_H = HAVE_GETOPT_H
>   INCLUDE_NEXT = include_next
> -PRAGMA_SYSTEM_HEADER = \#pragma GCC system_header
> +PRAGMA_SYSTEM_HEADER = ^#pragma GCC system_header
>   PRAGMA_COLUMNS =
>   NEXT_GETOPT_H = <getopt.h>
>   ARG_NONNULL_H = ../build-aux/snippet/arg-nonnull.h
> 
> This is not meant as a permanent fix, but just an example of what is 
> necessary to make it work with nmake.
> 
> See:
> http://msdn.microsoft.com/en-us/library/f8txf85h%28v=vs.80%29.aspx
> 
> Should we define an ESCAPE_SPECIAL_CHAR variable in 
> nmake.defs/gmake.defs to handle this or is there a way to make the 
> platform specific decision in the makefile.w32-in without too much 
> duplication?

This pragma is only needed when Emacs is compiled with MinGW, because
this pragma is specific to GCC.  So a better solution would be to
define PRAGMA_SYSTEM_HEADER itself on gmake.defs, and define it as
empty on nmake.defs (to edit away "@PRAGMA_SYSTEM_HEADER@").

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sat, 12 Nov 2011 18:55:37 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> Something seems to be messed up in the read_escape function :
> it should read the string "[?\\C-0]"
> it reads the 'C' and the '-', then it returns the char '0' + ctrl_modifier,
> and back in read1, the next char read is '0' again.
> Which means that in read1 at the failure point,
> next_char = 0x00000030
> and c = 0x04000030
> 
> I tried to step inside read_escape, but not sure what's going wrong here.

Can you show how the values of the following variables change as you
step through this fragment in read1 and inside read_escape it calls?

  read_from_string_index
  read_from_string_index_byte
  read_from_string_limit

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> Can you show how the values of the following variables change as you
> step through this fragment in read1 and inside read_escape it calls?
>
>  read_from_string_index
>  read_from_string_index_byte
>  read_from_string_limit
>

c 0x00000043 int
 read_from_string_index 0x00000004 int
 read_from_string_index_byte 0x00000004 int
 read_from_string_limit 0x00000008 int

case 'C':
  c = READCHAR;

c 0x0000002d int
 read_from_string_index 0x00000005 int
 read_from_string_index_byte 0x00000005 int
 read_from_string_limit 0x00000008 int

      if (c != '-')
error ("Invalid escape character syntax");
    case '^':
      c = READCHAR;

c 0x00000030 int
 read_from_string_index 0x00000006 int
 read_from_string_index_byte 0x00000006 int
 read_from_string_limit 0x00000008 int

return c | ctrl_modifier;

back to read1:

modifiers = c & CHAR_MODIFIER_MASK;
 c &= ~CHAR_MODIFIER_MASK;
if (CHAR_BYTE8_P (c))
  c = CHAR_TO_BYTE8 (c);
 c |= modifiers;

next_char = READCHAR;

 c 0x04000030 int
 next_char 0x00000030 int
read_from_string_index 0x00000007 int
 read_from_string_index_byte 0x00000007 int
 read_from_string_limit 0x00000008 int

ok = (next_char <= 040
      || (next_char < 0200
  && strchr ("\"';()[]#?`,.", next_char) != NULL));

                ok = 0 => error

Hope you can decipher this.

-- 
Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

The trick is that the string gets formatted this way :

s = [?\C-00], c= 43, index = 4, index_byte = 4

which is definitely wrong. It is format that is failing on this, not read.

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

Solved.

Int nt/inc/stdint.h, there is this constant :

#define UINT32_MAX 4294967296

which is obviously wrong and should be :

#define UINT32_MAX 4294967295

Fabrice



2011/11/12 Fabrice Popineau <fabrice.popineau@supelec.fr>

> The trick is that the string gets formatted this way :
>
> s = [?\C-00], c= 43, index = 4, index_byte = 4
>
> which is definitely wrong. It is format that is failing on this, not read.
>
> Fabrice
>
>


-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

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

bug#9960: Compiling Emacs trunk with MSVC

[Richard Stallman]

    I don't think that distributing msvcrt100.dll (or any proprietary
    binary) with a GNU binary is acceptable. But I'm not 100% sure, you'll
    better check in emacs-devel.

We certainly won't!

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9960: Compiling Emacs trunk with MSVC

[Christoph Scholtes]

On 11/12/2011 4:08 PM, Fabrice Popineau wrote:
> Solved.
>
> Int nt/inc/stdint.h, there is this constant :
>
> #define UINT32_MAX 4294967296
>
> which is obviously wrong and should be :
>
> #define UINT32_MAX 4294967295

Doh! Fixed. My apologies...

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

Just to let you know that emacs win64 compiles, dumps and loads.
There are still a couple of glitches. It does not yet bootstrap itself.

Main problems are :
- switch "long" to something that is 64 bits long when compiling for 64
bits architecture
- some functions are implicitly assumed to return an int because they are
not declared before being used
(one malloc() use in w32.c, sbrk() in gmalloc.c), hence they might generate
a sign extension, which is not good.

I will keep on polishing things up to the point it will bootstrap itself.

Greetings,

Fabrice

2011/11/10 Juanma Barranquero <lekktu@gmail.com>

> On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
> <fabrice.popineau@supelec.fr> wrote:
>
> > Is there any interest in having a 64bits windows emacs ?
>
> Yes.
>
>     Juanma
>

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

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau
<fabrice.popineau@supelec.fr> wrote:

> Just to let you know that emacs win64 compiles, dumps and loads.
> There are still a couple of glitches. It does not yet bootstrap itself.

Very cool, thanks.

You're using MSVC, not MinGW, I think? If so, we can tackle compiling
with MinGW (or TDM-GCC) later once you've got it all shiny.

> Main problems are :
> - switch "long" to something that is 64 bits long when compiling for 64 bits
> architecture

How is that solved when Emacs is compiled for 64-bit POSIX systems?

> - some functions are implicitly assumed to return an int because they are
> not declared before being used

There are lots of functions implictly declared. Compiling Emacs with
gcc's -Wimplicit-function-declaration flag gives 204 warnings, 56 of
them in w32*.c files. Though of course not all of them are relevant
(in some cases, the results are never used, etc.).

> I will keep on polishing things up to the point it will bootstrap itself.

Thanks a lot.

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau
> <fabrice.popineau@supelec.fr> wrote:
>
>> - some functions are implicitly assumed to return an int because they are
>> not declared before being used
>
> There are lots of functions implictly declared. Compiling Emacs with
> gcc's -Wimplicit-function-declaration flag gives 204 warnings, 56 of
> them in w32*.c files. Though of course not all of them are relevant
> (in some cases, the results are never used, etc.).

-Wimplicit-function-declaration has been turned on by default in
configure for more than a year.  On GNU/Linux (and probably most other
platforms that use configure+gcc)  -Wimplicit-function-declaration does
not produce any warnings.  Fixing all these warnings on windows too would be
a good idea...

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Sun, Nov 20, 2011 at 22:35, Dan Nicolaescu <dann@gnu.org> wrote:

> -Wimplicit-function-declaration has been turned on by default in
> configure for more than a year.  On GNU/Linux (and probably most other
> platforms that use configure+gcc)  -Wimplicit-function-declaration does
> not produce any warnings.

Ah, I didn't know that, thanks.

> Fixing all these warnings on windows too would be a good idea...

I will spend time on it after the release.

Thanks,

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Stefan Monnier]

>> - switch "long" to something that is 64 bits long when compiling for
>> 64 bits architecture
> How is that solved when Emacs is compiled for 64-bit POSIX systems?

I'm not sure I understand the question, but IIUC the answer is that
`long' is 64bit on all known 64bit POSIX systems.


        Stefan

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Mon, Nov 21, 2011 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm not sure I understand the question, but IIUC the answer is that
> `long' is 64bit on all known 64bit POSIX systems.

OK, let me rephrase the question to Fabrice (I thought that he meant
that there was some typedef or macro that he had to change, not
variables directly declared to be long):

Why it is a problem to "switch long to something that is 64 bits long
on a 64-bit architecture"? What is the problem exactly?

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 21 Nov 2011 03:45:06 +0100
> Cc: cschol2112@googlemail.com, Fabrice Popineau <fabrice.popineau@supelec.fr>,
> 	9960@debbugs.gnu.org
> 
> On Mon, Nov 21, 2011 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > I'm not sure I understand the question, but IIUC the answer is that
> > `long' is 64bit on all known 64bit POSIX systems.
> 
> OK, let me rephrase the question to Fabrice (I thought that he meant
> that there was some typedef or macro that he had to change, not
> variables directly declared to be long):
> 
> Why it is a problem to "switch long to something that is 64 bits long
> on a 64-bit architecture"? What is the problem exactly?

The hidden assumption is that a long and a pointer are of the same
width.  This is true on 32-bit hosts and on 64-bit Posix hosts (which
have the LP64 architecture), but not on 64-bit Windows, where long is
a 32-bit data type, but a pointer is 64-bit wide.

bug#9960: Compiling Emacs trunk with MSVC

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> 64-bit Posix hosts (which have the LP64 architecture),

There is no connection between POSIX and LP64.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  cschol2112@googlemail.com,  fabrice.popineau@supelec.fr,  9960@debbugs.gnu.org
> Date: Mon, 21 Nov 2011 09:21:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 64-bit Posix hosts (which have the LP64 architecture),
> 
> There is no connection between POSIX and LP64.

I didn't mean to say there was a connection, just that 64-bit Posix
hosts _happen_ to be LP64.  If I'm wrong, I'd like to know which Posix
platform is of a different kind, thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Juanma Barranquero]

On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii <eliz@gnu.org> wrote:

> The hidden assumption is that a long and a pointer are of the same
> width.  This is true on 32-bit hosts and on 64-bit Posix hosts (which
> have the LP64 architecture), but not on 64-bit Windows, where long is
> a 32-bit data type, but a pointer is 64-bit wide.

Aha, I see. So Fabrice is right: the code should not assume that, and
mixed uses of long/pointer will have to be "fixed".

    Juanma

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 21 Nov 2011 13:14:33 +0100
> Cc: monnier@iro.umontreal.ca, cschol2112@googlemail.com, 
> 	fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org
> 
> On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The hidden assumption is that a long and a pointer are of the same
> > width.  This is true on 32-bit hosts and on 64-bit Posix hosts (which
> > have the LP64 architecture), but not on 64-bit Windows, where long is
> > a 32-bit data type, but a pointer is 64-bit wide.
> 
> Aha, I see. So Fabrice is right: the code should not assume that, and
> mixed uses of long/pointer will have to be "fixed".

One way of fixing that would be to use ptrdiff_t instead of long, I
think.

bug#9960: Compiling Emacs trunk with MSVC

[Richard Stallman]

    Just to let you know that emacs win64 compiles, dumps and loads.

I am glad Emacs works on Windows 64, but please don't refer to that as
"win" -- it is a term of praise.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Thu, 10 Nov 2011 20:56:11 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> Sure. feel free to adapt on the basis of the attached patch.
> Status is :
> - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able to
> boostrap itself.
> - the 64 bits version compiles and dumps, but fails to bootstrap (seems to
> be looping inside elisp code).
> 
> Is there any interest in having a 64bits windows emacs ?
> 
> I have added two other files : a 64bits manifest for emacs.exe and a
> w32compat.h header file that is needed to compile the above mentioned
> libraries. In my case, this w32compat.h is included while compiling image.c
> for example.
> 
> Feel free to comment and adapt for the release version.

Thanks.  I think I made all the changes needed for the MSVC 32-bit
build.  You can try the latest bzr trunk, the changes are in revision
106533.  The next pretest of Emacs 24 is expected to be available
tomorrow, so if you can try building that and reporting back, that'd
be swell.

I'm leaving this bug open for now, in case I goofed and it still
doesn't build.

Please note that only some of the _WIN64 changes are committed.  I
didn't want to rock the boat too much during the pretest, and also I
really feel that we've exceeded the amount of changes we can accept
without legal papers.  (I'd really encourage you to sign papers at
some point, to make all this line-counting business unnecessary.)  And
I understand that you don't have a fully functional 64-bit version
anyway.  So I only committed those _WIN64 related changes that fix
what we already had in the repository.  The rest will have to wait for
after the release of Emacs 24.1.

Thank you for your help so far.

bug#9960: Compiling Emacs trunk with MSVC

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 27 Nov 2011 21:05:11 +0200, Eli Zaretskii <eliz@gnu.org> said:

> Thanks.  I think I made all the changes needed for the MSVC 32-bit
> build.  You can try the latest bzr trunk, the changes are in
> revision 106533.  The next pretest of Emacs 24 is expected to be
> available tomorrow, so if you can try building that and reporting
> back, that'd be swell.

=== modified file 'lib-src/emacsclient.c'
*** lib-src/emacsclient.c	2011-11-14 20:23:26 +0000
--- lib-src/emacsclient.c	2011-11-27 18:52:53 +0000
***************
*** 1635,1641 ****
    /* Send over our environment and current directory. */
    if (!current_frame)
      {
-       extern char **environ;
        int i;
        for (i = 0; environ[i]; i++)
          {
--- 1635,1640 ----



The above change in revno 106533 causes the following error in
compilation on Mac OS X 10.7.  I tried autogen.sh, make distclean, and
make bootstrap, but that didn't help.

.../lib-src/emacsclient.c: In function ‘main’:
.../lib-src/emacsclient.c:1639: error: ‘environ’ undeclared (first use in this function)
.../lib-src/emacsclient.c:1639: error: (Each undeclared identifier is reported only once
.../lib-src/emacsclient.c:1639: error: for each function it appears in.)
make[2]: *** [emacsclient] Error 1
make[1]: *** [lib-src] Error 2
make: *** [bootstrap] Error 2

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#9960: "emacsclient.c (main) <environ>: Remove declaration, " breaks build on Mac OS X

[David Caldwell]

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

FYI, I get this error when compiling Emacs for Mac OS X (x86_64, i386,
and  PowerPC):

> gcc -mmacosx-version-min=10.5 -std=gnu99   -Wimplicit-function-declaration -Wold-style-definition -Wdeclaration-after-statement  -DHAVE_CONFIG_H -I. -I../src -I../lib -I/Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src -I/Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/../src -I/Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/../lib    -g -O2 /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c \
> 	   -DVERSION="\"24.0.91\"" \
> 	   ../lib/libgnu.a  -o emacsclient
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c: In function 'set_local_socket':
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c:1281: warning: passing argument 2 of 'confstr' discards qualifiers from pointer target type
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c: In function 'main':
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c:1639: error: 'environ' undeclared (first use in this function)
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c:1639: error: (Each undeclared identifier is reported only once
> /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclient.c:1639: error: for each function it appears in.)

It appears to be caused by this checkin:

> revno: 106533
> fixes bug(s): http://debbugs.gnu.org/9960
> committer: Eli Zaretskii <eliz@gnu.org>
> branch nick: trunk
> timestamp: Sun 2011-11-27 20:52:53 +0200
> message:
>   Fix MS-Windows build with MSVC compiler.

I'm guessing it's this hunk:

=== modified file 'lib-src/emacsclient.c'
--- lib-src/emacsclient.c       2011-11-14 20:23:26 +0000
+++ lib-src/emacsclient.c       2011-11-27 18:52:53 +0000
@@ -1635,7 +1635,6 @@
   /* Send over our environment and current directory. */
   if (!current_frame)
     {
-      extern char **environ;
       int i;
       for (i = 0; environ[i]; i++)
         {

Thanks,
  David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 305 bytes --]

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Mon, 28 Nov 2011 18:18:54 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Fabrice Popineau <fabrice.popineau@supelec.fr>,
> 	cschol2112@googlemail.com,
> 	9960@debbugs.gnu.org
> 
> The above change in revno 106533 causes the following error in
> compilation on Mac OS X 10.7.  I tried autogen.sh, make distclean, and
> make bootstrap, but that didn't help.
> 
> .../lib-src/emacsclient.c: In function ‘main’:
> .../lib-src/emacsclient.c:1639: error: ‘environ’ undeclared (first use in this function)
> .../lib-src/emacsclient.c:1639: error: (Each undeclared identifier is reported only once
> .../lib-src/emacsclient.c:1639: error: for each function it appears in.)

Sorry about that.  Which system header declares `environ' on Mac OS X?
Does the problem go away if you include that header in emacsclient.c?

bug#9960: : "emacsclient.c (main) <environ>: Remove declaration, " breaks build on Mac OS X

[Leon Zhang]

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

I made this patch to fix this problem on my Mac. It worked on both my
ubuntu box and Mac (Lion), but I am not sure if it could work on other OSs.

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

[-- Attachment #2: 10_mac_environ.patch --]
[-- Type: application/octet-stream, Size: 964 bytes --]

diff --git a/lib/unistd.in.h b/lib/unistd.in.h
index 77e5675..759080a 100644
--- a/lib/unistd.in.h
+++ b/lib/unistd.in.h
@@ -382,17 +382,12 @@ _GL_WARN_ON_USE (dup3, "dup3 is unportable - "
 # if !@HAVE_DECL_ENVIRON@
 /* Set of environment variables and values.  An array of strings of the form
    "VARIABLE=VALUE", terminated with a NULL.  */
-#  if defined __APPLE__ && defined __MACH__
-#   include <crt_externs.h>
-#   define environ (*_NSGetEnviron ())
-#  else
-#   ifdef __cplusplus
+#  ifdef __cplusplus
 extern "C" {
-#   endif
+#  endif
 extern char **environ;
-#   ifdef __cplusplus
+#  ifdef __cplusplus
 }
-#   endif
 #  endif
 # endif
 #elif defined GNULIB_POSIXCHECK
@@ -407,6 +402,11 @@ _GL_WARN_ON_USE (rpl_environ, "environ is unportable - "
 #  undef environ
 #  define environ (*rpl_environ ())
 # endif
+#else
+# if defined __APPLE__ && defined __MACH__
+#  include <crt_externs.h>
+#  define environ (*_NSGetEnviron ())
+# endif
 #endif
 
 

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

On my side, there is still this messy 'tzname', which seems to be defined
in some part an not in some others.
I need the patch below.  It could probably be eliminated by a careful
analysis of what files are included.
I think the problem is that tzname may be defined to be _tzname _before_
including the regular MS <time.h> .

Greetings,

Fabrice


=== modified file 'lib/strftime.c'
--- lib/strftime.c      2011-03-31 04:24:03 +0000
+++ lib/strftime.c      2011-11-28 15:38:55 +0000
@@ -36,9 +36,13 @@
 #include <ctype.h>
 #include <time.h>

+#ifdef _MSC_VER
+#define tzname _tzname
+#else
 #if HAVE_TZNAME && !HAVE_DECL_TZNAME
 extern char *tzname[];
 #endif
+#endif

 /* Do multibyte processing if multibytes are supported, unless
    multibyte sequences are safe in formats.  Multibyte sequences are
=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h      2011-11-27 18:52:53 +0000
+++ src/s/ms-w32.h      2011-11-28 15:33:33 +0000
@@ -286,7 +286,9 @@
 #define stricmp   _stricmp
 #define tzset     _tzset

+#ifndef _MSC_VER
 #define tzname    _tzname
+#endif
 #if !defined (_MSC_VER) || (_MSC_VER < 1400)
 #undef  utime
 #define utime    _utime


2011/11/27 Eli Zaretskii <eliz@gnu.org>

> > From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> > Date: Thu, 10 Nov 2011 20:56:11 +0100
> > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> >
> > Sure. feel free to adapt on the basis of the attached patch.
> > Status is :
> > - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able
> to
> > boostrap itself.
> > - the 64 bits version compiles and dumps, but fails to bootstrap (seems
> to
> > be looping inside elisp code).
> >
> > Is there any interest in having a 64bits windows emacs ?
> >
> > I have added two other files : a 64bits manifest for emacs.exe and a
> > w32compat.h header file that is needed to compile the above mentioned
> > libraries. In my case, this w32compat.h is included while compiling
> image.c
> > for example.
> >
> > Feel free to comment and adapt for the release version.
>
> Thanks.  I think I made all the changes needed for the MSVC 32-bit
> build.  You can try the latest bzr trunk, the changes are in revision
> 106533.  The next pretest of Emacs 24 is expected to be available
> tomorrow, so if you can try building that and reporting back, that'd
> be swell.
>
> I'm leaving this bug open for now, in case I goofed and it still
> doesn't build.
>
> Please note that only some of the _WIN64 changes are committed.  I
> didn't want to rock the boat too much during the pretest, and also I
> really feel that we've exceeded the amount of changes we can accept
> without legal papers.  (I'd really encourage you to sign papers at
> some point, to make all this line-counting business unnecessary.)  And
> I understand that you don't have a fully functional 64-bit version
> anyway.  So I only committed those _WIN64 related changes that fix
> what we already had in the repository.  The rest will have to wait for
> after the release of Emacs 24.1.
>
> Thank you for your help so far.
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

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

bug#9960: Compiling Emacs trunk with MSVC

[Tim Crews]

[-- Attachment #1: Type: text/html, Size: 1079 bytes --]

bug#9960: Compiling Emacs trunk with MSVC

[Tim Crews]

[-- Attachment #1: Type: text/html, Size: 1141 bytes --]

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Wed, 30 Nov 2011 08:48:50 -0700
> From: Tim Crews <tim.crews@code-affinity.com>
> 
> <html>
>   <head>

Can you please not use HTML in email messages sent to here?

>     In a (misguided) effort to debug the linum-mode problem that I
>     reported yesterday
>     (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10164), I
>     attempted to build Emacs on my Windows 7 Pro SP1 64-bit machine
>     using MSVC; specifically using the Windows SDK 7.1 tools.
> 
>     The initial "nmake bootstrap" still does not work.

If you tried a 64-bit build, then it is not yet supported on Windows.
Try the 32-bit build, it should work.

>     the linum-mode bug was apparently caused by an issue with
>     gcc.

No, it wasn't.  But I fixed it already; try the next pretest when it
will be ready, hopefully in a day or two.

>     But back on 11/27 you asked someone to try a MSVC build, so here
>     you go.

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Tim Crews]

On 11/30/2011 11:04 AM, Eli Zaretskii wrote:
> Can you please not use HTML in email messages sent to here?

Yes, sorry about that.

> If you tried a 64-bit build, then it is not yet supported on Windows.
> Try the 32-bit build, it should work.

I was doing a 32-bit build.  There are still a few minor changes from 
Fabrice Popineau that haven't made it into bzr yet. 
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#224)   With those 
changes, the build succeeds.

>>      the linum-mode bug was apparently caused by an issue with
>>      gcc.
> No, it wasn't.  But I fixed it already; try the next pretest when it
> will be ready, hopefully in a day or two.
>
I built from the latest bzr source and can confirm that the linum-mode 
crash no longer occurs on my end.  Since the issue was not related to 
gcc after all, the fact that I built with MSVC presumably does not 
affect the validity of this finding.

Tim Crews

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> Date: Wed, 30 Nov 2011 11:22:05 -0700
> From: Tim Crews <tim.crews@code-affinity.com>
> Cc: 9960@debbugs.gnu.org
> 
> > If you tried a 64-bit build, then it is not yet supported on Windows.
> > Try the 32-bit build, it should work.
> 
> I was doing a 32-bit build.  There are still a few minor changes from 
> Fabrice Popineau that haven't made it into bzr yet. 
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#224)   With those 
> changes, the build succeeds.

Which changes, specifically, are needed?  I know only about one issue:
the one with _tzname.  The rest, to the best of my knowledge, are for
a 64-bit build.  If I'm wrong, I'd like to know which other changes
are still needed for the 32-bit build with MSVC.

> I built from the latest bzr source and can confirm that the linum-mode 
> crash no longer occurs on my end.

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Tim Crews]

On 11/30/2011 12:17 PM, Eli Zaretskii wrote:
>> Date: Wed, 30 Nov 2011 11:22:05 -0700
>> From: Tim Crews<tim.crews@code-affinity.com>
>> Cc: 9960@debbugs.gnu.org
>>
>>> If you tried a 64-bit build, then it is not yet supported on Windows.
>>> Try the 32-bit build, it should work.
>>
>> I was doing a 32-bit build.  There are still a few minor changes from
>> Fabrice Popineau that haven't made it into bzr yet.
>> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#224)   With those
>> changes, the build succeeds.
>
> Which changes, specifically, are needed?  I know only about one issue:
> the one with _tzname.  The rest, to the best of my knowledge, are for
> a 64-bit build.  If I'm wrong, I'd like to know which other changes
> are still needed for the 32-bit build with MSVC.
>
>> I built from the latest bzr source and can confirm that the linum-mode
>> crash no longer occurs on my end.
>
> Thanks.

There are only two changes listed in but 9960 message 224, both related 
to _tzname.  (The patch is repeated for reference at the bottom of this 
message.)  The changes are to lib/strftime.c and src/s/ms-w32.h.

If I back out Fabrice's proposed change to lib/strftime.c, the build 
succeeds through the compilation phase but fails to link because of 
unresolved external _tzname.

If I back out Fabrice's proposed change to src/s/ms-w32.h, compilation 
of ntlib.c fails with "time.h(270) : error C2090: function returns array".

So it appears that both changes are needed for the MSVC 32-bit build.

Tim Crews


=== modified file 'lib/strftime.c'
--- lib/strftime.c      2011-03-31 04:24:03 +0000
+++ lib/strftime.c      2011-11-28 15:38:55 +0000
@@ -36,9 +36,13 @@
  #include <ctype.h>
  #include <time.h>

+#ifdef _MSC_VER
+#define tzname _tzname
+#else
  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
  extern char *tzname[];
  #endif
+#endif

  /* Do multibyte processing if multibytes are supported, unless
     multibyte sequences are safe in formats.  Multibyte sequences are
=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h      2011-11-27 18:52:53 +0000
+++ src/s/ms-w32.h      2011-11-28 15:33:33 +0000
@@ -286,7 +286,9 @@
  #define stricmp   _stricmp
  #define tzset     _tzset

+#ifndef _MSC_VER
  #define tzname    _tzname
+#endif
  #if !defined (_MSC_VER) || (_MSC_VER < 1400)
  #undef  utime
  #define utime    _utime

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

Emacs compiles, bootstraps itself and loads on w64.
The diffs are not so large, I need to review them before
sending a patch, but they are mainly located in
alloc.c/gmalloc.c/ralloc.c .
I guess now I will have to use it a little bit to see if it is
stable. I'll try to put binaries on web access later this week
if anybody wants to test (64 bits dll are needed too, zlib and
so on).

Best regards,

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sun, 4 Dec 2011 09:06:21 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, monnier@iro.umontreal.ca, cschol2112@googlemail.com, 
> 	9960@debbugs.gnu.org
> 
> Emacs compiles, bootstraps itself and loads on w64.
> The diffs are not so large, I need to review them before
> sending a patch, but they are mainly located in
> alloc.c/gmalloc.c/ralloc.c .
> I guess now I will have to use it a little bit to see if it is
> stable. I'll try to put binaries on web access later this week
> if anybody wants to test (64 bits dll are needed too, zlib and
> so on).

Great, thanks.

If you don't mind, I'd urge you to sign legal papers.  That would
greatly simplify accepting changes from you in the future.  If you
agree, please ask Stefan Monnier <monnier@iro.umontreal.ca> or Chong
Yidong <cyd@gnu.org> to send you the paperwork.

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Mon, 28 Nov 2011 20:07:29 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> On my side, there is still this messy 'tzname', which seems to be defined
> in some part an not in some others.
> I need the patch below.  It could probably be eliminated by a careful
> analysis of what files are included.
> I think the problem is that tzname may be defined to be _tzname _before_
> including the regular MS <time.h> .

This should now be fixed (with trunk revision 107670).

Fabrice, please tell if there are any other problems that prevent the
32-bit MSVC build from working.  If no problems remain, I will close
this bug.

Thanks.

bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau]

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

>
> > On my side, there is still this messy 'tzname', which seems to be defined
> > in some part an not in some others.
> > I need the patch below.  It could probably be eliminated by a careful
> > analysis of what files are included.
> > I think the problem is that tzname may be defined to be _tzname _before_
> > including the regular MS <time.h> .
>
> This should now be fixed (with trunk revision 107670).
>
> Fabrice, please tell if there are any other problems that prevent the
> 32-bit MSVC build from working.  If no problems remain, I will close
> this bug.
>
>
It is working out of the box.
I did a bootstrap after configure.bat.
All I had to do was to set usercflags (graphics libraries and so on).

Thanks,

Fabrice

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

bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sat, 24 Mar 2012 17:10:16 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> > > On my side, there is still this messy 'tzname', which seems to be defined
> > > in some part an not in some others.
> > > I need the patch below.  It could probably be eliminated by a careful
> > > analysis of what files are included.
> > > I think the problem is that tzname may be defined to be _tzname _before_
> > > including the regular MS <time.h> .
> >
> > This should now be fixed (with trunk revision 107670).
> >
> > Fabrice, please tell if there are any other problems that prevent the
> > 32-bit MSVC build from working.  If no problems remain, I will close
> > this bug.
> >
> >
> It is working out of the box.
> I did a bootstrap after configure.bat.
> All I had to do was to set usercflags (graphics libraries and so on).

Great!  So I'm closing this bug.

Thanks for all your help.