GNU bug report logs - #9960
Compiling Emacs trunk with MSVC

Previous Next

Packages: w32, emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sat, 5 Nov 2011 11:24:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 11:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eli Zaretskii <eliz <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 05 Nov 2011 11:24:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 13:19:28 +0200
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
 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 11:44:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: fabrice.popineau <at> supelec.fr
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 13:39:45 +0200
> Date: Sat, 05 Nov 2011 13:19:28 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 12:58:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 06:54:39 -0600
On 11/5/2011 5:39 AM, Eli Zaretskii wrote:
>> Date: Sat, 05 Nov 2011 13:19:28 +0200
>> From: Eli Zaretskii<eliz <at> gnu.org>
>> Cc: 9960 <at> 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






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 13:27:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 15:22:52 +0200
> Date: Sat, 05 Nov 2011 06:54:39 -0600
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: fabrice.popineau <at> supelec.fr, 9960 <at> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 14:02:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 07:58:12 -0600
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 14:21:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:16:40 +0200
> Date: Sat, 05 Nov 2011 07:58:12 -0600
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: fabrice.popineau <at> supelec.fr, 9960 <at> 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__





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 14:58:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:53:11 +0200
> Date: Sat, 05 Nov 2011 16:16:40 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: fabrice.popineau <at> supelec.fr, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 15:55:01 GMT) Full text and rfc822 format available.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:51:55 +0100
Eli Zaretskii <eliz <at> 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

?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 16:16:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 18:10:38 +0200
> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Cc: cschol2112 <at> googlemail.com,  fabrice.popineau <at> supelec.fr,  9960 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2011 16:51:55 +0100
> 
> Eli Zaretskii <eliz <at> 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 16:31:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 10:27:50 -0600
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 16:56:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 18:50:02 +0200
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: fabrice.popineau <at> supelec.fr,  9960 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2011 10:27:50 -0600
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 17:03:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 18:57:57 +0200
> Date: Sat, 05 Nov 2011 18:50:02 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: fabrice.popineau <at> supelec.fr, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 17:26:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 11:22:58 -0600
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 18:24:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 12:20:22 -0600
Christoph Scholtes <cschol2112 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 19:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 21:33:51 +0200
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: fabrice.popineau <at> supelec.fr,  9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 20:36:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 14:32:15 -0600
Christoph Scholtes <cschol2112 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 20:42:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 14:38:41 -0600
Eli Zaretskii <eliz <at> 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. ;)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 21:19:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 23:11:49 +0200
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: fabrice.popineau <at> supelec.fr,  9960 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2011 14:38:41 -0600
> 
> Eli Zaretskii <eliz <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 21:33:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 23:27:44 +0200
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: fabrice.popineau <at> supelec.fr,  9960 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2011 14:32:15 -0600
> 
> Christoph Scholtes <cschol2112 <at> 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.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 22:11:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:07:39 -0600
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 `..'.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 22:19:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:15:06 -0600
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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 22:26:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:22:25 -0600
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 05 Nov 2011 22:27:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 16:23:40 -0600
Eli Zaretskii <eliz <at> 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];




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 01:06:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 6 Nov 2011 00:44:15 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 01:54:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 19:50:01 -0600
Christoph Scholtes <cschol2112 <at> 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 03:47:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 05 Nov 2011 21:42:58 -0600
Fabrice Popineau <fabrice.popineau <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 04:07:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 06 Nov 2011 06:02:04 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Sun, 6 Nov 2011 00:44:15 +0100
> Cc: 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 04:09:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 06 Nov 2011 06:03:10 +0200
> Date: Sat, 05 Nov 2011 16:22:25 -0600
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 05:41:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 06 Nov 2011 01:37:44 -0400
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: 9960 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2011 16:23:40 -0600
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 06 Nov 2011 05:51:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 06 Nov 2011 01:47:42 -0400
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> Cc: 9960 <at> 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).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Mon, 07 Nov 2011 16:17:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 7 Nov 2011 17:13:09 +0100
[Message part 1 (text/plain, inline)]
>
> > Christoph Scholtes <cschol2112 <at> 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Mon, 07 Nov 2011 17:04:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 07 Nov 2011 18:57:44 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Mon, 7 Nov 2011 17:13:09 +0100
> Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 9960 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Mon, 07 Nov 2011 17:09:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 07 Nov 2011 19:03:18 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Mon, 7 Nov 2011 17:13:09 +0100
> Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 9960 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Tue, 08 Nov 2011 06:47:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 9960 <at> debbugs.gnu.org
Subject: fix for Bug#9772 should also help fix Bug#9960
Date: Mon, 07 Nov 2011 22:43:46 -0800
[Message part 1 (text/plain, inline)]
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.

[stdalign1.txt (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Tue, 08 Nov 2011 16:57:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Tue, 08 Nov 2011 18:51:21 +0200
> From: Fabrice Popineau <fabrice.popineau <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Thu, 10 Nov 2011 19:57:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Thu, 10 Nov 2011 20:56:11 +0100
[Message part 1 (text/plain, inline)]
2011/11/7 Eli Zaretskii <eliz <at> 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
------------------------------
[Message part 2 (text/html, inline)]
[emacs-24-3.diff (application/octet-stream, attachment)]
[emacs-x64.manifest (application/octet-stream, attachment)]
[w32compat.h (text/x-chdr, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Thu, 10 Nov 2011 20:30:02 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Thu, 10 Nov 2011 21:28:49 +0100
On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
<fabrice.popineau <at> 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).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Thu, 10 Nov 2011 20:31:01 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Thu, 10 Nov 2011 21:29:26 +0100
On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
<fabrice.popineau <at> supelec.fr> wrote:

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

Yes.

    Juanma




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Thu, 10 Nov 2011 20:33:02 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Thu, 10 Nov 2011 21:31:49 +0100
On Thu, Nov 10, 2011 at 21:28, Lennart Borgman
<lennart.borgman <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Fri, 11 Nov 2011 09:43:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Fri, 11 Nov 2011 11:39:56 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Thu, 10 Nov 2011 20:56:11 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Fri, 11 Nov 2011 19:30:02 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Fri, 11 Nov 2011 20:28:21 +0100
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Fri, 11 Nov 2011 19:56:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Fri, 11 Nov 2011 21:53:24 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Fri, 11 Nov 2011 20:28:21 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Fri, 11 Nov 2011 21:57:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Fri, 11 Nov 2011 22:55:54 +0100
[Message part 1 (text/plain, inline)]
>
> > 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 13:54:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 15:50:35 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Fri, 11 Nov 2011 22:55:54 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 14:32:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 16:27:59 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Fri, 11 Nov 2011 20:28:21 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 14:36:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 15:34:56 +0100
[Message part 1 (text/plain, inline)]
>
> > 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 16:00:02 GMT) Full text and rfc822 format available.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 16:59:15 +0100
Fabrice Popineau <fabrice.popineau <at> 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]




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 17:12:01 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 10:10:34 -0700
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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 17:57:02 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 18:55:37 +0100
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 20:41:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 22:37:58 +0200
> Date: Sat, 12 Nov 2011 10:10:34 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 9960 <at> 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@").




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 20:52:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 22:48:00 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Sat, 12 Nov 2011 18:55:37 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 22:29:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 23:27:18 +0100
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 22:46:02 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 23:44:17 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 23:10:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 13 Nov 2011 00:08:47 +0100
[Message part 1 (text/plain, inline)]
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 <at> 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
------------------------------
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sat, 12 Nov 2011 23:34:01 GMT) Full text and rfc822 format available.

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

From: Richard Stallman <rms <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 18:32:57 -0500
    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/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs. (Sun, 13 Nov 2011 14:46:02 GMT) Full text and rfc822 format available.

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

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 13 Nov 2011 07:45:19 -0700
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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 20 Nov 2011 21:02:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
	cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 20 Nov 2011 21:59:49 +0100
[Message part 1 (text/plain, inline)]
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 <at> gmail.com>

> On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau
> <fabrice.popineau <at> supelec.fr> wrote:
>
> > Is there any interest in having a 64bits windows emacs ?
>
> Yes.
>
>     Juanma
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 20 Nov 2011 21:18:01 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 20 Nov 2011 22:15:15 +0100
On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau
<fabrice.popineau <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 20 Nov 2011 21:37:02 GMT) Full text and rfc822 format available.

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

From: Dan Nicolaescu <dann <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 20 Nov 2011 16:35:03 -0500
Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau
> <fabrice.popineau <at> 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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 20 Nov 2011 21:43:02 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 20 Nov 2011 22:40:35 +0100
On Sun, Nov 20, 2011 at 22:35, Dan Nicolaescu <dann <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 02:32:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 20 Nov 2011 21:30:13 -0500
>> - 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 02:48:01 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 03:45:06 +0100
On Mon, Nov 21, 2011 at 03:30, Stefan Monnier <monnier <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 03:55:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	monnier <at> iro.umontreal.ca, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 05:51:02 +0200
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 21 Nov 2011 03:45:06 +0100
> Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
> 	9960 <at> debbugs.gnu.org
> 
> On Mon, Nov 21, 2011 at 03:30, Stefan Monnier <monnier <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 08:24:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, Juanma Barranquero <lekktu <at> gmail.com>,
	fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 09:21:53 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

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

There is no connection between POSIX and LP64.

Andreas.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 09:56:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: cschol2112 <at> googlemail.com, lekktu <at> gmail.com, fabrice.popineau <at> supelec.fr,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 04:54:12 -0500
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>,  cschol2112 <at> googlemail.com,  fabrice.popineau <at> supelec.fr,  9960 <at> debbugs.gnu.org
> Date: Mon, 21 Nov 2011 09:21:53 +0100
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 12:17:02 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	monnier <at> iro.umontreal.ca, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 13:14:33 +0100
On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii <eliz <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 13:59:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	monnier <at> iro.umontreal.ca, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 08:56:50 -0500
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 21 Nov 2011 13:14:33 +0100
> Cc: monnier <at> iro.umontreal.ca, cschol2112 <at> googlemail.com, 
> 	fabrice.popineau <at> supelec.fr, 9960 <at> debbugs.gnu.org
> 
> On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 21 Nov 2011 15:58:02 GMT) Full text and rfc822 format available.

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

From: Richard Stallman <rms <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, lekktu <at> gmail.com, eliz <at> gnu.org,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 21 Nov 2011 10:55:39 -0500
    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/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 27 Nov 2011 19:08:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 27 Nov 2011 21:05:11 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Thu, 10 Nov 2011 20:56:11 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 28 Nov 2011 09:21:02 GMT) Full text and rfc822 format available.

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 28 Nov 2011 18:18:54 +0900
>>>>> On Sun, 27 Nov 2011 21:05:11 +0200, Eli Zaretskii <eliz <at> 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 <at> math.s.chiba-u.ac.jp




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 28 Nov 2011 09:37:02 GMT) Full text and rfc822 format available.

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

From: David Caldwell <david <at> porkrind.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: "emacsclient.c (main) <environ>: Remove declaration," breaks build
	on Mac OS X
Date: Mon, 28 Nov 2011 01:34:48 -0800
[Message part 1 (text/plain, inline)]
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 <at> 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

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 28 Nov 2011 11:54:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: cschol2112 <at> googlemail.com, fabrice.popineau <at> supelec.fr,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 28 Nov 2011 06:51:08 -0500
> Date: Mon, 28 Nov 2011 18:18:54 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Fabrice Popineau <fabrice.popineau <at> supelec.fr>,
> 	cschol2112 <at> googlemail.com,
> 	9960 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 28 Nov 2011 17:41:02 GMT) Full text and rfc822 format available.

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

From: Leon Zhang <leoncamel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: bug#9960 : "emacsclient.c (main) <environ>: Remove declaration,"
	breaks build on Mac OS X
Date: Tue, 29 Nov 2011 02:29:20 +0900
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
[10_mac_environ.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 28 Nov 2011 19:10:01 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 28 Nov 2011 20:07:29 +0100
[Message part 1 (text/plain, inline)]
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 <at> gnu.org>

> > From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> > Date: Thu, 10 Nov 2011 20:56:11 +0100
> > Cc: cschol2112 <at> googlemail.com, 9960 <at> 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
------------------------------
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 09:31:03 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Chong Yidong <cyd <at> gnu.org>
Cc: mario <at> lassnig.net, Eli Zaretskii <eliz <at> gnu.org>, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: OSX breakage
Date: Tue, 29 Nov 2011 01:28:30 -0800
On 11/28/11 21:00, Chong Yidong wrote:
> As Eli pointed out in the discussion on bug#10155, there is already code
> in lib/unistd.in.h that apparently ought to handle this, but itsn't
> working.

Here's a proposed patch to fix that, by having Emacs use Gnulib's
environ module.  This syncs from Gnulib, and so it also brings
in the patches for Bug#9772 and Bug#9960.  (It is possible to
pull out just the environ fix by hand, but that's an error-prone process
and I'd rather avoid it.)  I have tested this on Fedora 15,
but not on OSX nor on Windows.

# 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-27 18:33:17 +0000
+++ ChangeLog	2011-11-29 09:17:01 +0000
@@ -1,3 +1,25 @@
+2011-11-29  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Use Gnulib environ module.
+	* Makefile.in (GNULIB_MODULES): Add environ.
+	* m4/environ.m4: New file, from gnulib.
+
+	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.
+	* doc/misc/texinfo.tex, lib/gettext.h, lib/gnulib.mk:
+	* lib/md5.c, lib/sha1.c, lib/sha256.c, lib/sha512.c:
+	* lib/sigprocmask.c, lib/stdlib.in.h:
+	* m4/dup2.m4, m4/getopt.m4, m4/gl-comp.m4, m4/gnulib-common.m4:
+	* m4/include_next.m4, m4/pthread_sigmask.m4, m4/stdlib_h.m4:
+	* m4/unistd_h.m4: Merge from gnulib.
+
 2011-11-27  Jan Djärv  <jan.h.d <at> swipnet.se>
 
 	* configure.in: Check for gtk_window_set_has_resize_grip.

=== modified file 'Makefile.in'
--- Makefile.in	2011-11-22 01:56:49 +0000
+++ Makefile.in	2011-11-29 09:17:01 +0000
@@ -334,10 +334,10 @@
 GNULIB_MODULES = \
   alloca-opt \
   careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr \
-  dup2 \
+  dup2 environ \
   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-27 18:33:17 +0000
+++ configure.in	2011-11-28 16:07:26 +0000
@@ -1350,19 +1350,6 @@
 dnl Check for endianness.
 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-25 13:26:30 +0000
+++ doc/misc/ChangeLog	2011-11-29 09:17:01 +0000
@@ -1,3 +1,7 @@
+2011-11-29  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	* texinfo.tex: Merge from gnulib.
+
 2011-11-24  Glenn Morris  <rgm <at> gnu.org>
 
 	* gnus.texi, smtpmail.texi: Fix case of "GnuTLS".

=== modified file 'doc/misc/texinfo.tex'
--- doc/misc/texinfo.tex	2011-09-26 21:30:18 +0000
+++ doc/misc/texinfo.tex	2011-11-29 09:17:01 +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-09.15}
 %
 % 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\putworderror{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 <at> 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-11-29 09:17:01 +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 environ 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,7 +733,9 @@
 	      -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_PTSNAME_R''@/$(GNULIB_PTSNAME_R)/g' \
 	      -e 's/@''GNULIB_PUTENV''@/$(GNULIB_PUTENV)/g' \
 	      -e 's/@''GNULIB_RANDOM_R''@/$(GNULIB_RANDOM_R)/g' \
 	      -e 's/@''GNULIB_REALLOC_POSIX''@/$(GNULIB_REALLOC_POSIX)/g' \
@@ -736,7 +761,9 @@
 	      -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_PTSNAME_R''@|$(HAVE_PTSNAME_R)|g' \
 	      -e 's|@''HAVE_RANDOM_H''@|$(HAVE_RANDOM_H)|g' \
 	      -e 's|@''HAVE_RANDOM_R''@|$(HAVE_RANDOM_R)|g' \
 	      -e 's|@''HAVE_REALPATH''@|$(HAVE_REALPATH)|g' \
@@ -754,6 +781,7 @@
 	      -e 's|@''REPLACE_MALLOC''@|$(REPLACE_MALLOC)|g' \
 	      -e 's|@''REPLACE_MBTOWC''@|$(REPLACE_MBTOWC)|g' \
 	      -e 's|@''REPLACE_MKSTEMP''@|$(REPLACE_MKSTEMP)|g' \
+	      -e 's|@''REPLACE_PTSNAME_R''@|$(REPLACE_PTSNAME_R)|g' \
 	      -e 's|@''REPLACE_PUTENV''@|$(REPLACE_PUTENV)|g' \
 	      -e 's|@''REPLACE_REALLOC''@|$(REPLACE_REALLOC)|g' \
 	      -e 's|@''REPLACE_REALPATH''@|$(REPLACE_REALPATH)|g' \
@@ -1004,7 +1032,7 @@
 	      -e 's/@''GNULIB_SYMLINK''@/$(GNULIB_SYMLINK)/g' \
 	      -e 's/@''GNULIB_SYMLINKAT''@/$(GNULIB_SYMLINKAT)/g' \
 	      -e 's/@''GNULIB_TTYNAME_R''@/$(GNULIB_TTYNAME_R)/g' \
-	      -e 's/@''GNULIB_UNISTD_H_GETOPT''@/$(GNULIB_UNISTD_H_GETOPT)/g' \
+	      -e 's/@''GNULIB_UNISTD_H_GETOPT''@/0$(GNULIB_GL_UNISTD_H_GETOPT)/g' \
 	      -e 's/@''GNULIB_UNISTD_H_NONBLOCKING''@/$(GNULIB_UNISTD_H_NONBLOCKING)/g' \
 	      -e 's/@''GNULIB_UNISTD_H_SIGPIPE''@/$(GNULIB_UNISTD_H_SIGPIPE)/g' \
 	      -e 's/@''GNULIB_UNLINK''@/$(GNULIB_UNLINK)/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-11-20 03:48:53 +0000
+++ lib/sha256.c	2011-11-29 09:17:01 +0000
@@ -24,7 +24,8 @@
 
 #include "sha256.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -51,7 +52,7 @@
 
 /*
   Takes a pointer to a 256 bit block of data (eight 32 bit ints) and
-  initializes it to the start constants of the SHA256 algorithm.  This
+  intializes it to the start constants of the SHA256 algorithm.  This
   must be called before using hash in the call to sha256_hash
 */
 void
@@ -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-11-20 03:48:53 +0000
+++ lib/sha512.c	2011-11-29 09:17:01 +0000
@@ -24,7 +24,8 @@
 
 #include "sha512.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -58,7 +59,7 @@
 
 /*
   Takes a pointer to a 512 bit block of data (eight 64 bit ints) and
-  initializes it to the start constants of the SHA512 algorithm.  This
+  intializes it to the start constants of the SHA512 algorithm.  This
   must be called before using hash in the call to sha512_hash
 */
 void
@@ -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)
           {

=== modified file 'lib/sigprocmask.c'
--- lib/sigprocmask.c	2011-10-07 21:15:00 +0000
+++ lib/sigprocmask.c	2011-11-29 09:17:01 +0000
@@ -344,5 +344,6 @@
       else if (handler != SIG_IGN)
         (*handler) (SIGPIPE);
     }
+  return 0;
 }
 #endif

=== 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-29 09:17:01 +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.  */
@@ -439,6 +455,32 @@
 # endif
 #endif
 
+#if @GNULIB_PTSNAME_R@
+/* Set the pathname of the pseudo-terminal slave associated with
+   the master FD is open on and return 0, or set errno and return
+   non-zero on errors.  */
+# if @REPLACE_PTSNAME_R@
+#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
+#   undef ptsname_r
+#   define ptsname_r rpl_ptsname_r
+#  endif
+_GL_FUNCDECL_RPL (ptsname_r, int, (int fd, char *buf, size_t len));
+_GL_CXXALIAS_RPL (ptsname_r, int, (int fd, char *buf, size_t len));
+# else
+#  if !@HAVE_PTSNAME_R@
+_GL_FUNCDECL_SYS (ptsname_r, int, (int fd, char *buf, size_t len));
+#  endif
+_GL_CXXALIAS_SYS (ptsname_r, int, (int fd, char *buf, size_t len));
+# endif
+_GL_CXXALIASWARN (ptsname_r);
+#elif defined GNULIB_POSIXCHECK
+# undef ptsname_r
+# if HAVE_RAW_DECL_PTSNAME_R
+_GL_WARN_ON_USE (ptsname_r, "ptsname_r is not portable - "
+                 "use gnulib module ptsname_r for portability");
+# endif
+#endif
+
 #if @GNULIB_PUTENV@
 # if @REPLACE_PUTENV@
 #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)

=== modified file 'm4/dup2.m4'
--- m4/dup2.m4	2011-09-26 21:30:18 +0000
+++ m4/dup2.m4	2011-11-29 09:17:01 +0000
@@ -1,4 +1,4 @@
-#serial 16
+#serial 17
 dnl Copyright (C) 2002, 2005, 2007, 2009-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,
@@ -67,7 +67,9 @@
   m4_ifdef([gl_FUNC_FCHDIR], [
     gl_TEST_FCHDIR
     if test $HAVE_FCHDIR = 0; then
-      REPLACE_DUP2=1
+      if test $HAVE_DUP2 = 1; then
+        REPLACE_DUP2=1
+      fi
     fi
   ])
 ])

=== added file 'm4/environ.m4'
--- m4/environ.m4	1970-01-01 00:00:00 +0000
+++ m4/environ.m4	2011-11-29 09:17:01 +0000
@@ -0,0 +1,47 @@
+# environ.m4 serial 6
+dnl Copyright (C) 2001-2004, 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,
+dnl with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN_ONCE([gl_ENVIRON],
+[
+  AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
+  dnl Persuade glibc <unistd.h> to declare environ.
+  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+  AC_CHECK_HEADERS_ONCE([unistd.h])
+  gt_CHECK_VAR_DECL(
+    [#if HAVE_UNISTD_H
+     #include <unistd.h>
+     #endif
+     /* mingw, BeOS, Haiku declare environ in <stdlib.h>, not in <unistd.h>.  */
+     #include <stdlib.h>
+    ],
+    [environ])
+  if test $gt_cv_var_environ_declaration != yes; then
+    HAVE_DECL_ENVIRON=0
+  fi
+])
+
+# Check if a variable is properly declared.
+# gt_CHECK_VAR_DECL(includes,variable)
+AC_DEFUN([gt_CHECK_VAR_DECL],
+[
+  define([gt_cv_var], [gt_cv_var_]$2[_declaration])
+  AC_MSG_CHECKING([if $2 is properly declared])
+  AC_CACHE_VAL([gt_cv_var], [
+    AC_COMPILE_IFELSE(
+      [AC_LANG_PROGRAM(
+         [[$1
+           extern struct { int foo; } $2;]],
+         [[$2.foo = 1;]])],
+      [gt_cv_var=no],
+      [gt_cv_var=yes])])
+  AC_MSG_RESULT([$gt_cv_var])
+  if test $gt_cv_var = yes; then
+    AC_DEFINE([HAVE_]m4_translit($2, [a-z], [A-Z])[_DECL], 1,
+              [Define if you have the declaration of $2.])
+  fi
+  undefine([gt_cv_var])
+])

=== modified file 'm4/getopt.m4'
--- m4/getopt.m4	2011-07-24 22:15:47 +0000
+++ m4/getopt.m4	2011-11-29 09:17:01 +0000
@@ -1,4 +1,4 @@
-# getopt.m4 serial 38
+# getopt.m4 serial 39
 dnl Copyright (C) 2002-2006, 2008-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,
@@ -25,8 +25,6 @@
   if test $REPLACE_GETOPT = 1; then
     dnl Arrange for getopt.h to be created.
     gl_GETOPT_SUBSTITUTE_HEADER
-    dnl Arrange for unistd.h to include getopt.h.
-    GNULIB_UNISTD_H_GETOPT=1
   fi
 ])
 

=== modified file 'm4/gl-comp.m4'
--- m4/gl-comp.m4	2011-10-07 21:15:00 +0000
+++ m4/gl-comp.m4	2011-11-29 09:17:01 +0000
@@ -48,6 +48,7 @@
   # Code from module dosname:
   # Code from module dtoastr:
   # Code from module dup2:
+  # Code from module environ:
   # Code from module extensions:
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   # Code from module filemode:
@@ -76,6 +77,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,
@@ -130,6 +132,8 @@
   gl_PREREQ_DUP2
 fi
 gl_UNISTD_MODULE_INDICATOR([dup2])
+gl_ENVIRON
+gl_UNISTD_MODULE_INDICATOR([environ])
 gl_FILEMODE
 gl_GETLOADAVG
 if test $HAVE_GETLOADAVG = 0; then
@@ -142,14 +146,20 @@
   AC_LIBOBJ([getopt])
   AC_LIBOBJ([getopt1])
   gl_PREREQ_GETOPT
+  dnl Arrange for unistd.h to include getopt.h.
+  GNULIB_GL_UNISTD_H_GETOPT=1
 fi
+AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT])
 gl_MODULE_INDICATOR_FOR_TESTS([getopt-gnu])
 gl_FUNC_GETOPT_POSIX
 if test $REPLACE_GETOPT = 1; then
   AC_LIBOBJ([getopt])
   AC_LIBOBJ([getopt1])
   gl_PREREQ_GETOPT
+  dnl Arrange for unistd.h to include getopt.h.
+  GNULIB_GL_UNISTD_H_GETOPT=1
 fi
+AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT])
 AC_REQUIRE([AC_C_INLINE])
 gl_INTTYPES_INCOMPLETE
 gl_FUNC_LSTAT
@@ -180,6 +190,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 +322,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 +524,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
@@ -538,6 +550,7 @@
   m4/alloca.m4
   m4/c-strtod.m4
   m4/dup2.m4
+  m4/environ.m4
   m4/extensions.m4
   m4/filemode.m4
   m4/getloadavg.m4
@@ -563,6 +576,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/gnulib-common.m4'
--- m4/gnulib-common.m4	2011-10-07 21:15:00 +0000
+++ m4/gnulib-common.m4	2011-11-29 09:17:01 +0000
@@ -18,7 +18,7 @@
 # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
       || 0x5110 <= __SUNPRO_C)
 #  define _Noreturn __attribute__ ((__noreturn__))
-# elif 1200 <= _MSC_VER
+# elif defined _MSC_VER && 1200 <= _MSC_VER
 #  define _Noreturn __declspec (noreturn)
 # else
 #  define _Noreturn

=== 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-11-29 09:17:01 +0000
@@ -1,4 +1,4 @@
-# stdlib_h.m4 serial 37
+# stdlib_h.m4 serial 39
 dnl Copyright (C) 2007-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,
@@ -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 ptsname_r random_r realpath rpmatch setenv setstate_r srandom_r
+    strtod strtoll strtoull unlockpt unsetenv])
 ])
 
 AC_DEFUN([gl_STDLIB_MODULE_INDICATOR],
@@ -50,7 +50,9 @@
   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_PTSNAME_R=0;     AC_SUBST([GNULIB_PTSNAME_R])
   GNULIB_PUTENV=0;        AC_SUBST([GNULIB_PUTENV])
   GNULIB_RANDOM_R=0;      AC_SUBST([GNULIB_RANDOM_R])
   GNULIB_REALLOC_POSIX=0; AC_SUBST([GNULIB_REALLOC_POSIX])
@@ -76,7 +78,9 @@
   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_PTSNAME_R=1;          AC_SUBST([HAVE_PTSNAME_R])
   HAVE_RANDOM_H=1;           AC_SUBST([HAVE_RANDOM_H])
   HAVE_RANDOM_R=1;           AC_SUBST([HAVE_RANDOM_R])
   HAVE_REALPATH=1;           AC_SUBST([HAVE_REALPATH])
@@ -95,6 +99,7 @@
   REPLACE_MALLOC=0;          AC_SUBST([REPLACE_MALLOC])
   REPLACE_MBTOWC=0;          AC_SUBST([REPLACE_MBTOWC])
   REPLACE_MKSTEMP=0;         AC_SUBST([REPLACE_MKSTEMP])
+  REPLACE_PTSNAME_R=0;       AC_SUBST([REPLACE_PTSNAME_R])
   REPLACE_PUTENV=0;          AC_SUBST([REPLACE_PUTENV])
   REPLACE_REALLOC=0;         AC_SUBST([REPLACE_REALLOC])
   REPLACE_REALPATH=0;        AC_SUBST([REPLACE_REALPATH])

=== modified file 'm4/unistd_h.m4'
--- m4/unistd_h.m4	2011-09-26 21:30:18 +0000
+++ m4/unistd_h.m4	2011-11-29 09:17:01 +0000
@@ -1,4 +1,4 @@
-# unistd_h.m4 serial 61
+# unistd_h.m4 serial 62
 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,
@@ -98,7 +98,6 @@
   GNULIB_SYMLINK=0;              AC_SUBST([GNULIB_SYMLINK])
   GNULIB_SYMLINKAT=0;            AC_SUBST([GNULIB_SYMLINKAT])
   GNULIB_TTYNAME_R=0;            AC_SUBST([GNULIB_TTYNAME_R])
-  GNULIB_UNISTD_H_GETOPT=0;      AC_SUBST([GNULIB_UNISTD_H_GETOPT])
   GNULIB_UNISTD_H_NONBLOCKING=0; AC_SUBST([GNULIB_UNISTD_H_NONBLOCKING])
   GNULIB_UNISTD_H_SIGPIPE=0;     AC_SUBST([GNULIB_UNISTD_H_SIGPIPE])
   GNULIB_UNLINK=0;               AC_SUBST([GNULIB_UNLINK])

=== 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 <at> 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 <at> 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-27 18:52:53 +0000
+++ nt/ChangeLog	2011-11-28 16:07:26 +0000
@@ -1,3 +1,8 @@
+2011-11-28  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Use Gnulib stdalign module (Bug#9772, Bug#9960).
+	* config.nt (HAVE_ATTRIBUTE_ALIGNED): Remove.
+
 2011-11-27  Fabrice Popineau  <fabrice.popineau <at> supelec.fr>  (tiny change)
 
 	* inc/stdint.h (uint32_t, uint64_t) [_WIN64]: New typedefs.

=== modified file 'nt/config.nt'
--- nt/config.nt	2011-11-27 18:52:53 +0000
+++ nt/config.nt	2011-11-28 16:07:26 +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-28 08:20:58 +0000
+++ src/ChangeLog	2011-11-28 16:07:26 +0000
@@ -1,3 +1,14 @@
+2011-11-08  Paul Eggert  <eggert <at> 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-28  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	Remove GCPRO-related macros that exist only to avoid shadowing locals.

=== modified file 'src/alloc.c'
--- src/alloc.c	2011-11-20 03:07:02 +0000
+++ src/alloc.c	2011-11-28 16:07:26 +0000
@@ -507,12 +507,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
@@ -4235,15 +4230,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. */
@@ -4662,17 +4657,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-28 08:20:58 +0000
+++ src/lisp.h	2011-11-28 16:07:26 +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,27 +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 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(ALIGN_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.  */
@@ -309,6 +291,14 @@
     Lisp_Fwd_Kboard_Obj,	/* Fwd to a Lisp_Object field of kboards.  */
   };
 
+#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.  */
 #ifndef VALBITS
 #define VALBITS (BITS_PER_EMACS_INT - GCTYPEBITS)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 13:59:03 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mario <at> lassnig.net, Chong Yidong <cyd <at> gnu.org>, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: bug#10155: OSX breakage
Date: Tue, 29 Nov 2011 08:56:38 -0500
> --- .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

Shouldn't these be covered by a glob lib/*.h instead?

> +	Use Gnulib stdalign module (Bug#9772, Bug#9960).

As already explained, we don't want this change now.  Syncing gnulib
shouldn't impose such a change.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 16:43:03 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mario <at> lassnig.net, cyd <at> gnu.org, 9772 <at> debbugs.gnu.org, 9960 <at> debbugs.gnu.org,
	10155 <at> debbugs.gnu.org
Subject: Re: OSX breakage
Date: Tue, 29 Nov 2011 18:39:56 +0200
> Date: Tue, 29 Nov 2011 01:28:30 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>, mario <at> lassnig.net, 
>  9772 <at> debbugs.gnu.org, 9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
> 
> On 11/28/11 21:00, Chong Yidong wrote:
> > As Eli pointed out in the discussion on bug#10155, there is already code
> > in lib/unistd.in.h that apparently ought to handle this, but itsn't
> > working.
> 
> Here's a proposed patch to fix that, by having Emacs use Gnulib's
> environ module.  This syncs from Gnulib, and so it also brings
> in the patches for Bug#9772 and Bug#9960.  (It is possible to
> pull out just the environ fix by hand, but that's an error-prone process
> and I'd rather avoid it.)  I have tested this on Fedora 15,
> but not on OSX nor on Windows.

FWIW, I'd very much prefer not to install such large changes a day or
two before the next pretest.  If the only practical way of fixing this
within gnulib is the proposed changeset, I'd say let's just add a
declaration of environ conditioned on OS X and FreeBSD.  I don't like
this solution, but I think on balance it has less potential for
destabilizing the build.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 17:01:03 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: mario <at> lassnig.net, 9960 <at> debbugs.gnu.org, Chong Yidong <cyd <at> gnu.org>,
	9772 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#10155: OSX breakage
Date: Tue, 29 Nov 2011 08:58:34 -0800
On 11/29/11 05:56, Stefan Monnier wrote:
>> --- .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
> 
> Shouldn't these be covered by a glob lib/*.h instead?

No, because the pattern "lib/*.h" would match many files that are
checked in under bzr and that we don't want bzr to ignore, such as
lib/allocator.h and lib/min-max.h.

> Syncing gnulib shouldn't impose such a change.

You're right, on further thought Emacs itself needn't use stdalign,
and I've prepared a simpler patch (below) that omits all changes to
src/*.  Gnulib now uses stdalign, though, and Emacs uses
multiple Gnulib modules such as sha256 that use stdalign, so
this patch still brings in the stdalign module for Gnulib's own
purposes.

About 90% of the following patch is automatically generated by the
sync from gnulib.  The only parts that aren't automatic are the
changes to Makefile.in, .bzrignore, config.bat, msdos/sedlibmk.inp,
and the ChangeLog files.  I've reordered the patch to list these
changes first, for easier reviewing.  I'm also CC'ing this to Eli
as the proposed config.bat and msdos changes affect Microsoft builds.

=== modified file 'ChangeLog'
--- ChangeLog	2011-11-27 18:33:17 +0000
+++ ChangeLog	2011-11-29 16:38:21 +0000
@@ -1,3 +1,19 @@
+2011-11-29  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Use Gnulib environ module, syncing from Gnulib.
+	* Makefile.in (GNULIB_MODULES): Add environ.
+	* m4/environ.m4: New file, from gnulib.
+	* lib/stdalign.in.h, m4/environ.m4, m4/stdalign.m4:
+	New files, from gnulib.
+	* .bzrignore: Add lib/stdalign.h.
+	* config.bat: Copy lib/stdalign.in.h to lib/stdalign.in-h as needed.
+	* doc/misc/texinfo.tex, lib/gettext.h, lib/gnulib.mk:
+	* lib/md5.c, lib/sha1.c, lib/sha256.c, lib/sha512.c:
+	* lib/sigprocmask.c, lib/stdlib.in.h:
+	* m4/dup2.m4, m4/getopt.m4, m4/gl-comp.m4, m4/gnulib-common.m4:
+	* m4/include_next.m4, m4/pthread_sigmask.m4, m4/stdlib_h.m4:
+	* m4/unistd_h.m4: Merge from gnulib.
+
 2011-11-27  Jan Djärv  <jan.h.d <at> swipnet.se>
 
 	* configure.in: Check for gtk_window_set_has_resize_grip.

=== modified file 'Makefile.in'
--- Makefile.in	2011-11-22 01:56:49 +0000
+++ Makefile.in	2011-11-29 16:38:21 +0000
@@ -334,7 +334,7 @@
 GNULIB_MODULES = \
   alloca-opt \
   careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr \
-  dup2 \
+  dup2 environ \
   filemode getloadavg getopt-gnu ignore-value intprops lstat \
   mktime pthread_sigmask readlink \
   socklen stdarg stdio strftime strtoimax strtoumax symlink sys_stat

=== modified file '.bzrignore'
--- .bzrignore	2011-09-29 14:19:11 +0000
+++ .bzrignore	2011-11-29 16:38:21 +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 'config.bat'
--- config.bat	2011-10-31 17:49:10 +0000
+++ config.bat	2011-11-29 16:38:21 +0000
@@ -283,6 +283,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 +347,3 @@
 set djgpp_ver=

 set sys_malloc=

 set libxml=

-


=== modified file 'msdos/ChangeLog'
--- msdos/ChangeLog	2011-10-31 17:37:39 +0000
+++ msdos/ChangeLog	2011-11-29 16:38:21 +0000
@@ -1,3 +1,9 @@
+2011-11-29  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Adjust to Gnulib stdalign module.
+	* sedlibmk.inp (STDALIGN_H, @GL_GENERATE_STDALIGN_H_TRUE@)
+	(GL_GENERATE_STDALIGN_H_FALSE): New edits.
+
 2011-10-31  Eli Zaretskii  <eliz <at> gnu.org>
 
 	* sed3v2.inp (insrcdir): Comment out definition.

=== modified file 'msdos/sedlibmk.inp'
--- msdos/sedlibmk.inp	2011-09-29 12:00:18 +0000
+++ msdos/sedlibmk.inp	2011-11-29 16:38:21 +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 'doc/misc/ChangeLog'
--- doc/misc/ChangeLog	2011-11-25 13:26:30 +0000
+++ doc/misc/ChangeLog	2011-11-29 16:38:21 +0000
@@ -1,3 +1,7 @@
+2011-11-29  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	* texinfo.tex: Sync from gnulib.
+
 2011-11-24  Glenn Morris  <rgm <at> gnu.org>
 
 	* gnus.texi, smtpmail.texi: Fix case of "GnuTLS".

=== modified file 'doc/misc/texinfo.tex'
--- doc/misc/texinfo.tex	2011-09-26 21:30:18 +0000
+++ doc/misc/texinfo.tex	2011-11-29 16:38:21 +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-09.15}
 %
 % 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\putworderror{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 <at> t
 }
 }%end \catcode `\@=11

=== modified file 'lib/gettext.h'
--- lib/gettext.h	2011-02-15 04:53:29 +0000
+++ lib/gettext.h	2011-11-29 16:38:21 +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-11-29 16:38:21 +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 environ filemode getloadavg getopt-gnu ignore-value intprops lstat mktime pthread_sigmask readlink socklen 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,7 +733,9 @@
 	      -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_PTSNAME_R''@/$(GNULIB_PTSNAME_R)/g' \
 	      -e 's/@''GNULIB_PUTENV''@/$(GNULIB_PUTENV)/g' \
 	      -e 's/@''GNULIB_RANDOM_R''@/$(GNULIB_RANDOM_R)/g' \
 	      -e 's/@''GNULIB_REALLOC_POSIX''@/$(GNULIB_REALLOC_POSIX)/g' \
@@ -736,7 +761,9 @@
 	      -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_PTSNAME_R''@|$(HAVE_PTSNAME_R)|g' \
 	      -e 's|@''HAVE_RANDOM_H''@|$(HAVE_RANDOM_H)|g' \
 	      -e 's|@''HAVE_RANDOM_R''@|$(HAVE_RANDOM_R)|g' \
 	      -e 's|@''HAVE_REALPATH''@|$(HAVE_REALPATH)|g' \
@@ -754,6 +781,7 @@
 	      -e 's|@''REPLACE_MALLOC''@|$(REPLACE_MALLOC)|g' \
 	      -e 's|@''REPLACE_MBTOWC''@|$(REPLACE_MBTOWC)|g' \
 	      -e 's|@''REPLACE_MKSTEMP''@|$(REPLACE_MKSTEMP)|g' \
+	      -e 's|@''REPLACE_PTSNAME_R''@|$(REPLACE_PTSNAME_R)|g' \
 	      -e 's|@''REPLACE_PUTENV''@|$(REPLACE_PUTENV)|g' \
 	      -e 's|@''REPLACE_REALLOC''@|$(REPLACE_REALLOC)|g' \
 	      -e 's|@''REPLACE_REALPATH''@|$(REPLACE_REALPATH)|g' \
@@ -1004,7 +1032,7 @@
 	      -e 's/@''GNULIB_SYMLINK''@/$(GNULIB_SYMLINK)/g' \
 	      -e 's/@''GNULIB_SYMLINKAT''@/$(GNULIB_SYMLINKAT)/g' \
 	      -e 's/@''GNULIB_TTYNAME_R''@/$(GNULIB_TTYNAME_R)/g' \
-	      -e 's/@''GNULIB_UNISTD_H_GETOPT''@/$(GNULIB_UNISTD_H_GETOPT)/g' \
+	      -e 's/@''GNULIB_UNISTD_H_GETOPT''@/0$(GNULIB_GL_UNISTD_H_GETOPT)/g' \
 	      -e 's/@''GNULIB_UNISTD_H_NONBLOCKING''@/$(GNULIB_UNISTD_H_NONBLOCKING)/g' \
 	      -e 's/@''GNULIB_UNISTD_H_SIGPIPE''@/$(GNULIB_UNISTD_H_SIGPIPE)/g' \
 	      -e 's/@''GNULIB_UNLINK''@/$(GNULIB_UNLINK)/g' \

=== modified file 'lib/md5.c'
--- lib/md5.c	2011-02-19 07:28:29 +0000
+++ lib/md5.c	2011-11-29 16:38:21 +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-11-29 16:38:21 +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-11-20 03:48:53 +0000
+++ lib/sha256.c	2011-11-29 16:38:21 +0000
@@ -24,7 +24,8 @@
 
 #include "sha256.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -51,7 +52,7 @@
 
 /*
   Takes a pointer to a 256 bit block of data (eight 32 bit ints) and
-  initializes it to the start constants of the SHA256 algorithm.  This
+  intializes it to the start constants of the SHA256 algorithm.  This
   must be called before using hash in the call to sha256_hash
 */
 void
@@ -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-11-20 03:48:53 +0000
+++ lib/sha512.c	2011-11-29 16:38:21 +0000
@@ -24,7 +24,8 @@
 
 #include "sha512.h"
 
-#include <stddef.h>
+#include <stdalign.h>
+#include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
 
@@ -58,7 +59,7 @@
 
 /*
   Takes a pointer to a 512 bit block of data (eight 64 bit ints) and
-  initializes it to the start constants of the SHA512 algorithm.  This
+  intializes it to the start constants of the SHA512 algorithm.  This
   must be called before using hash in the call to sha512_hash
 */
 void
@@ -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)
           {

=== modified file 'lib/sigprocmask.c'
--- lib/sigprocmask.c	2011-10-07 21:15:00 +0000
+++ lib/sigprocmask.c	2011-11-29 16:38:21 +0000
@@ -344,5 +344,6 @@
       else if (handler != SIG_IGN)
         (*handler) (SIGPIPE);
     }
+  return 0;
 }
 #endif

=== added file 'lib/stdalign.in.h'
--- lib/stdalign.in.h	1970-01-01 00:00:00 +0000
+++ lib/stdalign.in.h	2011-11-29 16:38:21 +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-29 16:38:21 +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.  */
@@ -439,6 +455,32 @@
 # endif
 #endif
 
+#if @GNULIB_PTSNAME_R@
+/* Set the pathname of the pseudo-terminal slave associated with
+   the master FD is open on and return 0, or set errno and return
+   non-zero on errors.  */
+# if @REPLACE_PTSNAME_R@
+#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
+#   undef ptsname_r
+#   define ptsname_r rpl_ptsname_r
+#  endif
+_GL_FUNCDECL_RPL (ptsname_r, int, (int fd, char *buf, size_t len));
+_GL_CXXALIAS_RPL (ptsname_r, int, (int fd, char *buf, size_t len));
+# else
+#  if !@HAVE_PTSNAME_R@
+_GL_FUNCDECL_SYS (ptsname_r, int, (int fd, char *buf, size_t len));
+#  endif
+_GL_CXXALIAS_SYS (ptsname_r, int, (int fd, char *buf, size_t len));
+# endif
+_GL_CXXALIASWARN (ptsname_r);
+#elif defined GNULIB_POSIXCHECK
+# undef ptsname_r
+# if HAVE_RAW_DECL_PTSNAME_R
+_GL_WARN_ON_USE (ptsname_r, "ptsname_r is not portable - "
+                 "use gnulib module ptsname_r for portability");
+# endif
+#endif
+
 #if @GNULIB_PUTENV@
 # if @REPLACE_PUTENV@
 #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)

=== modified file 'm4/dup2.m4'
--- m4/dup2.m4	2011-09-26 21:30:18 +0000
+++ m4/dup2.m4	2011-11-29 16:38:21 +0000
@@ -1,4 +1,4 @@
-#serial 16
+#serial 17
 dnl Copyright (C) 2002, 2005, 2007, 2009-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,
@@ -67,7 +67,9 @@
   m4_ifdef([gl_FUNC_FCHDIR], [
     gl_TEST_FCHDIR
     if test $HAVE_FCHDIR = 0; then
-      REPLACE_DUP2=1
+      if test $HAVE_DUP2 = 1; then
+        REPLACE_DUP2=1
+      fi
     fi
   ])
 ])

=== added file 'm4/environ.m4'
--- m4/environ.m4	1970-01-01 00:00:00 +0000
+++ m4/environ.m4	2011-11-29 16:38:21 +0000
@@ -0,0 +1,47 @@
+# environ.m4 serial 6
+dnl Copyright (C) 2001-2004, 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,
+dnl with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN_ONCE([gl_ENVIRON],
+[
+  AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
+  dnl Persuade glibc <unistd.h> to declare environ.
+  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+  AC_CHECK_HEADERS_ONCE([unistd.h])
+  gt_CHECK_VAR_DECL(
+    [#if HAVE_UNISTD_H
+     #include <unistd.h>
+     #endif
+     /* mingw, BeOS, Haiku declare environ in <stdlib.h>, not in <unistd.h>.  */
+     #include <stdlib.h>
+    ],
+    [environ])
+  if test $gt_cv_var_environ_declaration != yes; then
+    HAVE_DECL_ENVIRON=0
+  fi
+])
+
+# Check if a variable is properly declared.
+# gt_CHECK_VAR_DECL(includes,variable)
+AC_DEFUN([gt_CHECK_VAR_DECL],
+[
+  define([gt_cv_var], [gt_cv_var_]$2[_declaration])
+  AC_MSG_CHECKING([if $2 is properly declared])
+  AC_CACHE_VAL([gt_cv_var], [
+    AC_COMPILE_IFELSE(
+      [AC_LANG_PROGRAM(
+         [[$1
+           extern struct { int foo; } $2;]],
+         [[$2.foo = 1;]])],
+      [gt_cv_var=no],
+      [gt_cv_var=yes])])
+  AC_MSG_RESULT([$gt_cv_var])
+  if test $gt_cv_var = yes; then
+    AC_DEFINE([HAVE_]m4_translit($2, [a-z], [A-Z])[_DECL], 1,
+              [Define if you have the declaration of $2.])
+  fi
+  undefine([gt_cv_var])
+])

=== modified file 'm4/getopt.m4'
--- m4/getopt.m4	2011-07-24 22:15:47 +0000
+++ m4/getopt.m4	2011-11-29 16:38:21 +0000
@@ -1,4 +1,4 @@
-# getopt.m4 serial 38
+# getopt.m4 serial 39
 dnl Copyright (C) 2002-2006, 2008-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,
@@ -25,8 +25,6 @@
   if test $REPLACE_GETOPT = 1; then
     dnl Arrange for getopt.h to be created.
     gl_GETOPT_SUBSTITUTE_HEADER
-    dnl Arrange for unistd.h to include getopt.h.
-    GNULIB_UNISTD_H_GETOPT=1
   fi
 ])
 

=== modified file 'm4/gl-comp.m4'
--- m4/gl-comp.m4	2011-10-07 21:15:00 +0000
+++ m4/gl-comp.m4	2011-11-29 16:38:21 +0000
@@ -48,6 +48,7 @@
   # Code from module dosname:
   # Code from module dtoastr:
   # Code from module dup2:
+  # Code from module environ:
   # Code from module extensions:
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   # Code from module filemode:
@@ -76,6 +77,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,
@@ -130,6 +132,8 @@
   gl_PREREQ_DUP2
 fi
 gl_UNISTD_MODULE_INDICATOR([dup2])
+gl_ENVIRON
+gl_UNISTD_MODULE_INDICATOR([environ])
 gl_FILEMODE
 gl_GETLOADAVG
 if test $HAVE_GETLOADAVG = 0; then
@@ -142,14 +146,20 @@
   AC_LIBOBJ([getopt])
   AC_LIBOBJ([getopt1])
   gl_PREREQ_GETOPT
+  dnl Arrange for unistd.h to include getopt.h.
+  GNULIB_GL_UNISTD_H_GETOPT=1
 fi
+AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT])
 gl_MODULE_INDICATOR_FOR_TESTS([getopt-gnu])
 gl_FUNC_GETOPT_POSIX
 if test $REPLACE_GETOPT = 1; then
   AC_LIBOBJ([getopt])
   AC_LIBOBJ([getopt1])
   gl_PREREQ_GETOPT
+  dnl Arrange for unistd.h to include getopt.h.
+  GNULIB_GL_UNISTD_H_GETOPT=1
 fi
+AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT])
 AC_REQUIRE([AC_C_INLINE])
 gl_INTTYPES_INCOMPLETE
 gl_FUNC_LSTAT
@@ -180,6 +190,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 +322,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 +524,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
@@ -538,6 +550,7 @@
   m4/alloca.m4
   m4/c-strtod.m4
   m4/dup2.m4
+  m4/environ.m4
   m4/extensions.m4
   m4/filemode.m4
   m4/getloadavg.m4
@@ -563,6 +576,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/gnulib-common.m4'
--- m4/gnulib-common.m4	2011-10-07 21:15:00 +0000
+++ m4/gnulib-common.m4	2011-11-29 16:38:21 +0000
@@ -18,7 +18,7 @@
 # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
       || 0x5110 <= __SUNPRO_C)
 #  define _Noreturn __attribute__ ((__noreturn__))
-# elif 1200 <= _MSC_VER
+# elif defined _MSC_VER && 1200 <= _MSC_VER
 #  define _Noreturn __declspec (noreturn)
 # else
 #  define _Noreturn

=== modified file 'm4/include_next.m4'
--- m4/include_next.m4	2011-09-26 21:30:18 +0000
+++ m4/include_next.m4	2011-11-29 16:38:21 +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-11-29 16:38:21 +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-11-29 16:38:21 +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-11-29 16:38:21 +0000
@@ -1,4 +1,4 @@
-# stdlib_h.m4 serial 37
+# stdlib_h.m4 serial 39
 dnl Copyright (C) 2007-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,
@@ -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 ptsname_r random_r realpath rpmatch setenv setstate_r srandom_r
+    strtod strtoll strtoull unlockpt unsetenv])
 ])
 
 AC_DEFUN([gl_STDLIB_MODULE_INDICATOR],
@@ -50,7 +50,9 @@
   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_PTSNAME_R=0;     AC_SUBST([GNULIB_PTSNAME_R])
   GNULIB_PUTENV=0;        AC_SUBST([GNULIB_PUTENV])
   GNULIB_RANDOM_R=0;      AC_SUBST([GNULIB_RANDOM_R])
   GNULIB_REALLOC_POSIX=0; AC_SUBST([GNULIB_REALLOC_POSIX])
@@ -76,7 +78,9 @@
   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_PTSNAME_R=1;          AC_SUBST([HAVE_PTSNAME_R])
   HAVE_RANDOM_H=1;           AC_SUBST([HAVE_RANDOM_H])
   HAVE_RANDOM_R=1;           AC_SUBST([HAVE_RANDOM_R])
   HAVE_REALPATH=1;           AC_SUBST([HAVE_REALPATH])
@@ -95,6 +99,7 @@
   REPLACE_MALLOC=0;          AC_SUBST([REPLACE_MALLOC])
   REPLACE_MBTOWC=0;          AC_SUBST([REPLACE_MBTOWC])
   REPLACE_MKSTEMP=0;         AC_SUBST([REPLACE_MKSTEMP])
+  REPLACE_PTSNAME_R=0;       AC_SUBST([REPLACE_PTSNAME_R])
   REPLACE_PUTENV=0;          AC_SUBST([REPLACE_PUTENV])
   REPLACE_REALLOC=0;         AC_SUBST([REPLACE_REALLOC])
   REPLACE_REALPATH=0;        AC_SUBST([REPLACE_REALPATH])

=== modified file 'm4/unistd_h.m4'
--- m4/unistd_h.m4	2011-09-26 21:30:18 +0000
+++ m4/unistd_h.m4	2011-11-29 16:38:21 +0000
@@ -1,4 +1,4 @@
-# unistd_h.m4 serial 61
+# unistd_h.m4 serial 62
 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,
@@ -98,7 +98,6 @@
   GNULIB_SYMLINK=0;              AC_SUBST([GNULIB_SYMLINK])
   GNULIB_SYMLINKAT=0;            AC_SUBST([GNULIB_SYMLINKAT])
   GNULIB_TTYNAME_R=0;            AC_SUBST([GNULIB_TTYNAME_R])
-  GNULIB_UNISTD_H_GETOPT=0;      AC_SUBST([GNULIB_UNISTD_H_GETOPT])
   GNULIB_UNISTD_H_NONBLOCKING=0; AC_SUBST([GNULIB_UNISTD_H_NONBLOCKING])
   GNULIB_UNISTD_H_SIGPIPE=0;     AC_SUBST([GNULIB_UNISTD_H_SIGPIPE])
   GNULIB_UNLINK=0;               AC_SUBST([GNULIB_UNLINK])






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 17:33:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mario <at> lassnig.net, 9960 <at> debbugs.gnu.org, cyd <at> gnu.org, 9772 <at> debbugs.gnu.org,
	10155 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#10155: OSX breakage
Date: Tue, 29 Nov 2011 19:30:30 +0200
> Date: Tue, 29 Nov 2011 08:58:34 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Chong Yidong <cyd <at> gnu.org>, mario <at> lassnig.net, 9772 <at> debbugs.gnu.org, 
>  9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org, 
>  Eli Zaretskii <eliz <at> gnu.org>
> 
> You're right, on further thought Emacs itself needn't use stdalign,
> and I've prepared a simpler patch (below) that omits all changes to
> src/*.  Gnulib now uses stdalign, though, and Emacs uses
> multiple Gnulib modules such as sha256 that use stdalign, so
> this patch still brings in the stdalign module for Gnulib's own
> purposes.

I understand that the only part needed for solving the problems with
the missing declaration of `environ' is this:

> === added file 'm4/environ.m4'
> --- m4/environ.m4	1970-01-01 00:00:00 +0000
> +++ m4/environ.m4	2011-11-29 16:38:21 +0000
> @@ -0,0 +1,47 @@
> +# environ.m4 serial 6
> +dnl Copyright (C) 2001-2004, 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,
> +dnl with or without modifications, as long as this notice is preserved.
> +
> +AC_DEFUN_ONCE([gl_ENVIRON],
> +[
> +  AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
> +  dnl Persuade glibc <unistd.h> to declare environ.
> +  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
> +
> +  AC_CHECK_HEADERS_ONCE([unistd.h])
> +  gt_CHECK_VAR_DECL(
> +    [#if HAVE_UNISTD_H
> +     #include <unistd.h>
> +     #endif
> +     /* mingw, BeOS, Haiku declare environ in <stdlib.h>, not in <unistd.h>.  */
> +     #include <stdlib.h>
> +    ],
> +    [environ])
> +  if test $gt_cv_var_environ_declaration != yes; then
> +    HAVE_DECL_ENVIRON=0
> +  fi
> +])

IOW, the reason why lib/unistd.in.h didn't do its job is that
HAVE_DECL_ENVIRON was not defined to zero.

If that is true, I wonder if we could have a much smaller change that
fixes just that single problem.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Tue, 29 Nov 2011 18:25:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mario <at> lassnig.net, 9960 <at> debbugs.gnu.org, cyd <at> gnu.org, 9772 <at> debbugs.gnu.org,
	10155 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#10155: OSX breakage
Date: Tue, 29 Nov 2011 10:22:19 -0800
On 11/29/11 09:30, Eli Zaretskii wrote:
> I wonder if we could have a much smaller change that
> fixes just that single problem.

Yes we could, though it would involve more of the patch
than the part that you've identified, and it would involve
some other stuff done by hand.  The simplest way to think
about it is, I expect, is that it would be a fork of gnulib.
I could look into preparing such a patch but it would take
some time and would introduce other reliability concerns,
so I hope I don't have to do that....




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 02:28:02 GMT) Full text and rfc822 format available.

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

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mario <at> lassnig.net, Paul Eggert <eggert <at> cs.ucla.edu>, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: OSX breakage
Date: Wed, 30 Nov 2011 10:27:16 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Here's a proposed patch to fix that, by having Emacs use Gnulib's
>> environ module.  This syncs from Gnulib, and so it also brings
>> in the patches for Bug#9772 and Bug#9960.  (It is possible to
>> pull out just the environ fix by hand, but that's an error-prone process
>> and I'd rather avoid it.)  I have tested this on Fedora 15,
>> but not on OSX nor on Windows.
>
> FWIW, I'd very much prefer not to install such large changes a day or
> two before the next pretest.  If the only practical way of fixing this
> within gnulib is the proposed changeset, I'd say let's just add a
> declaration of environ conditioned on OS X and FreeBSD.  I don't like
> this solution, but I think on balance it has less potential for
> destabilizing the build.

Agreed.  Paul, can you pick out just the environ fix?  If not, we should
go with the ifdefs as Eli suggested, and leave any Gnulib synch for
post-24.1.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 02:46:02 GMT) Full text and rfc822 format available.

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

From: Chong Yidong <cyd <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mario <at> lassnig.net, Eli Zaretskii <eliz <at> gnu.org>, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: bug#9772: bug#10155: OSX breakage
Date: Wed, 30 Nov 2011 10:45:42 +0800
Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 11/29/11 09:30, Eli Zaretskii wrote:
>> I wonder if we could have a much smaller change that
>> fixes just that single problem.
>
> Yes we could, though it would involve more of the patch
> than the part that you've identified, and it would involve
> some other stuff done by hand.  The simplest way to think
> about it is, I expect, is that it would be a fork of gnulib.
> I could look into preparing such a patch but it would take
> some time and would introduce other reliability concerns,
> so I hope I don't have to do that....

OK, then let's go with the ifdef conditioning directly in the Emacs
sources.

But is conditioning on OS X and FreeBSD the right thing?  We don't know
if it fails on other BSDs.  Since revno 106533 was intended to fix the
MS-WINDOWS build, I think it's better to condition it for WINDOWSNT for
now, as below:

Eli, WDYT?

=== modified file 'lib-src/emacsclient.c'
*** lib-src/emacsclient.c	2011-11-27 18:52:53 +0000
--- lib-src/emacsclient.c	2011-11-30 02:44:47 +0000
***************
*** 1635,1640 ****
--- 1635,1645 ----
    /* Send over our environment and current directory. */
    if (!current_frame)
      {
+ #ifndef WINDOWSNT
+       /* This is defined in stdlib.h on MS-Windows.  It's defined in
+ 	 unistd.h on some POSIX hosts, but not all (Bug#10155).  */
+       extern char **environ;
+ #endif
        int i;
        for (i = 0; environ[i]; i++)
          {





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 04:06:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: mario <at> lassnig.net, eggert <at> cs.ucla.edu, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: bug#9772: bug#10155: OSX breakage
Date: Wed, 30 Nov 2011 06:04:20 +0200
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  mario <at> lassnig.net,  9960 <at> debbugs.gnu.org,  9772 <at> debbugs.gnu.org,  10155 <at> debbugs.gnu.org
> Date: Wed, 30 Nov 2011 10:45:42 +0800
> 
> OK, then let's go with the ifdef conditioning directly in the Emacs
> sources.
> 
> But is conditioning on OS X and FreeBSD the right thing?  We don't know
> if it fails on other BSDs.  Since revno 106533 was intended to fix the
> MS-WINDOWS build, I think it's better to condition it for WINDOWSNT for
> now, as below:
> 
> Eli, WDYT?

Fine with me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 08:15:03 GMT) Full text and rfc822 format available.

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

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mario <at> lassnig.net, eggert <at> cs.ucla.edu, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: bug#9772: bug#10155: OSX breakage
Date: Wed, 30 Nov 2011 16:14:28 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

>> OK, then let's go with the ifdef conditioning directly in the Emacs
>> sources.
>>
>> But is conditioning on OS X and FreeBSD the right thing?  We don't know
>> if it fails on other BSDs.  Since revno 106533 was intended to fix the
>> MS-WINDOWS build, I think it's better to condition it for WINDOWSNT for
>> now, as below:
>>
>> Eli, WDYT?
>
> Fine with me.

Done.  Could someone check if compilation on Mac OS X works now?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 17:50:01 GMT) Full text and rfc822 format available.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> gnu.org>
Cc: mario <at> lassnig.net, eggert <at> cs.ucla.edu, 9960 <at> debbugs.gnu.org,
	9772 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#10155: bug#9772: bug#10155: OSX breakage
Date: Wed, 30 Nov 2011 18:48:49 +0100
30 nov 2011 kl. 09:14 skrev Chong Yidong:

> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> OK, then let's go with the ifdef conditioning directly in the Emacs
>>> sources.
>>> 
>>> But is conditioning on OS X and FreeBSD the right thing?  We don't know
>>> if it fails on other BSDs.  Since revno 106533 was intended to fix the
>>> MS-WINDOWS build, I think it's better to condition it for WINDOWSNT for
>>> now, as below:
>>> 
>>> Eli, WDYT?
>> 
>> Fine with me.
> 
> Done.  Could someone check if compilation on Mac OS X works now?
> 
> 


It does.

	Jan D.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 17:51:02 GMT) Full text and rfc822 format available.

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

From: Tim Crews <tim.crews <at> code-affinity.com>
To: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 08:48:50 -0700
[Message part 1 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 17:51:02 GMT) Full text and rfc822 format available.

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

From: Tim Crews <tim.crews <at> code-affinity.com>
To: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 09:30:05 -0700
[Message part 1 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 17:52:02 GMT) Full text and rfc822 format available.

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

From: Mario Lassnig <mario <at> lassnig.net>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 9772 <at> debbugs.gnu.org,
	9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: Re: bug#9772: bug#10155: OSX breakage
Date: Wed, 30 Nov 2011 12:15:10 +0100
On 11-11-30 9:14 , Chong Yidong wrote:
> Eli Zaretskii<eliz <at> gnu.org>  writes:
>
>>> OK, then let's go with the ifdef conditioning directly in the Emacs
>>> sources.
>>>
>>> But is conditioning on OS X and FreeBSD the right thing?  We don't know
>>> if it fails on other BSDs.  Since revno 106533 was intended to fix the
>>> MS-WINDOWS build, I think it's better to condition it for WINDOWSNT for
>>> now, as below:
>>>
>>> Eli, WDYT?
>>
>> Fine with me.
>
> Done.  Could someone check if compilation on Mac OS X works now?

Looks good to me. Compiles, installs, runs. :-)

Thanks,
Mario





Mario <at> shodan:~/Development/emacs$ bzr clone 
bzr://bzr.savannah.gnu.org/emacs/trunk/
The command 'bzr clone' has been deprecated in bzr 2.4. Please use 'bzr 
branch' instead.
Branched 106554 revision(s). 

Mario <at> shodan:~/Development/emacs$ cd trunk/
Mario <at> shodan:~/Development/emacs/trunk$ echo $CFLAGS
-march=core2 -msse4.1
Mario <at> shodan:~/Development/emacs/trunk$ echo $CC

Mario <at> shodan:~/Development/emacs/trunk$ which gcc
/usr/bin/gcc
Mario <at> shodan:~/Development/emacs/trunk$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Mario <at> shodan:~/Development/emacs/trunk$ sh autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
configure.in:635: installing `build-aux/compile'
configure.in:379: installing `build-aux/config.guess'
configure.in:379: installing `build-aux/config.sub'
configure.in:29: installing `build-aux/install-sh'
configure.in:29: installing `build-aux/missing'
lib/Makefile.am: installing `build-aux/depcomp'
You can now run `./configure'.
Mario <at> shodan:~/Development/emacs/trunk$ ./configure --with-ns

<snip>

Configured for `x86_64-apple-darwin11.2.0'.

  Where should the build process find the source code? 
/Users/Mario/Development/emacs/trunk
  What operating system and machine description files should Emacs use?
        `s/darwin.h' and `m/amdx86-64.h'
  What compiler should emacs be built with?               gcc 
-std=gnu99 -march=core2 -msse4.1
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    nextstep
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   /usr/X11/lib
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   no
  Does Emacs use -ljpeg?                                  no
  Does Emacs use -ltiff?                                  no
  Does Emacs use a gif library?                           no
  Does Emacs use -lpng?                                   no
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use imagemagick?                             no
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              no
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use toolkit scroll bars?                     yes





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 18:06:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Crews <tim.crews <at> code-affinity.com>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 20:04:19 +0200
> Date: Wed, 30 Nov 2011 08:48:50 -0700
> From: Tim Crews <tim.crews <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 18:28:02 GMT) Full text and rfc822 format available.

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

From: Tim Crews <tim.crews <at> code-affinity.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 11:22:05 -0700
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 19:20:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Crews <tim.crews <at> code-affinity.com>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 21:17:49 +0200
> Date: Wed, 30 Nov 2011 11:22:05 -0700
> From: Tim Crews <tim.crews <at> code-affinity.com>
> Cc: 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Wed, 30 Nov 2011 19:43:02 GMT) Full text and rfc822 format available.

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

From: Tim Crews <tim.crews <at> code-affinity.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Wed, 30 Nov 2011 12:42:08 -0700
On 11/30/2011 12:17 PM, Eli Zaretskii wrote:
>> Date: Wed, 30 Nov 2011 11:22:05 -0700
>> From: Tim Crews<tim.crews <at> code-affinity.com>
>> Cc: 9960 <at> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Thu, 01 Dec 2011 16:14:02 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: mario <at> lassnig.net
Cc: Eli Zaretskii <eliz <at> gnu.org>, Chong Yidong <cyd <at> gnu.org>,
	9772 <at> debbugs.gnu.org, 9960 <at> debbugs.gnu.org, 10155-done <at> debbugs.gnu.org
Subject: Re: bug#9772: bug#10155: OSX breakage
Date: Thu, 01 Dec 2011 08:12:57 -0800
On 11/30/11 03:15, Mario Lassnig wrote:
> Looks good to me. Compiles, installs, runs. 

Thanks for checking.  I'll mark Bug#10155 as done since the bug
itself is fixed.  The cleaner fix for 'environ' can wait until
after Emacs 24 is out.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sun, 04 Dec 2011 08:08:02 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, Juanma Barranquero <lekktu <at> gmail.com>,
	monnier <at> iro.umontreal.ca, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sun, 4 Dec 2011 09:06:21 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Mon, 05 Dec 2011 05:12:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, lekktu <at> gmail.com, monnier <at> iro.umontreal.ca,
	9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 05 Dec 2011 00:11:02 -0500
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Sun, 4 Dec 2011 09:06:21 +0100
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, monnier <at> iro.umontreal.ca, cschol2112 <at> googlemail.com, 
> 	9960 <at> 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 <at> iro.umontreal.ca> or Chong
Yidong <cyd <at> gnu.org> to send you the paperwork.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sat, 24 Mar 2012 14:18:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 24 Mar 2012 15:46:09 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Mon, 28 Nov 2011 20:07:29 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#9960; Package emacs,w32. (Sat, 24 Mar 2012 16:42:02 GMT) Full text and rfc822 format available.

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

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 24 Mar 2012 17:10:16 +0100
[Message part 1 (text/plain, inline)]
>
> > 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
[Message part 2 (text/html, inline)]

Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 24 Mar 2012 19:14:02 GMT) Full text and rfc822 format available.

Notification sent to Eli Zaretskii <eliz <at> gnu.org>:
bug acknowledged by developer. (Sat, 24 Mar 2012 19:14:02 GMT) Full text and rfc822 format available.

Message #298 received at 9960-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
Cc: cschol2112 <at> googlemail.com, 9960-done <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 24 Mar 2012 20:42:21 +0200
> From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> Date: Sat, 24 Mar 2012 17:10:16 +0100
> Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 22 Apr 2012 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 333 days ago.

Previous Next


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