From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 11:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: 9960@debbugs.gnu.org X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.13204921916412 (code B ref -1); Sat, 05 Nov 2011 11:24:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Nov 2011 11:23:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeL8-0001fM-QS for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:23:11 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeL5-0001fE-Fe for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMeIT-0005Lw-8N for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:20:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:32953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIT-0005Ls-6d for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:20:25 -0400 Received: from eggs.gnu.org ([140.186.70.92]:40003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIQ-0000Eb-FP for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMeIN-0005LP-FR for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:22 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:64032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIM-0005L4-Pq for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:19 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU600100Q14FF00@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 13:20:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU60013SQ5D9190@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 13:20:03 +0200 (IST) Date: Sat, 05 Nov 2011 13:19:28 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8339e2lsu7.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) 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 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 + +#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 +#include +#include +#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 +#endif #include === 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 #include +#ifndef _MSC_VER #include +#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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 11:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: fabrice.popineau@supelec.fr Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132049339310878 (code B ref 9960); Sat, 05 Nov 2011 11:44:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 11:43:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeeX-0002pP-DP for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:43:13 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeeT-0002pD-07 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 07:43:10 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU600100QYSSO00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 13:40:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU600127R3991E0@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 13:40:22 +0200 (IST) Date: Sat, 05 Nov 2011 13:39:45 +0200 From: Eli Zaretskii In-reply-to: <8339e2lsu7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83zkgakdby.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 05 Nov 2011 13:19:28 +0200 > From: Eli Zaretskii > Cc: 9960@debbugs.gnu.org > > What follows is discussion of some of the changes suggested by > Fabrice, including the description of how they were adapted to the > current trunk, and the diffs that will be actually committed shortly. Committed as revision 106292 on the trunk. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 12:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132049785617379 (code B ref 9960); Sat, 05 Nov 2011 12:58:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 12:57:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMfoV-0004WF-Gi for submit@debbugs.gnu.org; Sat, 05 Nov 2011 08:57:36 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMfoT-0004W8-G0 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 08:57:34 -0400 Received: by ywt2 with SMTP id 2so3363011ywt.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 05:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FQGRZq1A7RvzRv0WDfNvwq8PVLqrDDTtQxjcLtzZ7H4=; b=G1dJCtqoFdNWGtd7JPzqtPubEnlEkSxbtCSoK6J5V9UDFutfVMDFfRj4788G+LCWY2 N4szQhSNGoQWaKl5CfKLqSGE44YLB2w+7NJ+2EB+/FIdYMkuCj7MbwyxApgtH231ZNyK 78D31HcMgFgzajqSr/iv6SgArK9cG8xTekyE4= Received: by 10.42.144.65 with SMTP id a1mr24824444icv.46.1320497692692; Sat, 05 Nov 2011 05:54:52 -0700 (PDT) Received: from [192.168.1.4] (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id bu33sm28018308ibb.11.2011.11.05.05.54.51 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 05:54:51 -0700 (PDT) Message-ID: <4EB5320F.5090800@gmail.com> Date: Sat, 05 Nov 2011 06:54:39 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> In-Reply-To: <83zkgakdby.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) On 11/5/2011 5:39 AM, Eli Zaretskii wrote: >> Date: Sat, 05 Nov 2011 13:19:28 +0200 >> From: Eli Zaretskii >> Cc: 9960@debbugs.gnu.org >> >> What follows is discussion of some of the changes suggested by >> Fabrice, including the description of how they were adapted to the >> current trunk, and the diffs that will be actually committed shortly. > > Committed as revision 106292 on the trunk. I tried building with Visual Studio 2008 (Express Edition) and the build fails: cl -I. -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd -Zi -DEMACSDEBUG -DENA BLE_CHECKING -DXASSERTS -I"D:/devel/emacs/libs/libXpm-3.5.8/include" -I"D:/devel /emacs/libs/libXpm-3.5.8/src" -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" -I"D:/devel/emacs/libs/giflib- 4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" -I"D:/devel/emacs/lib s/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" -DHAVE_CON FIG_H=1 -I. -I../nt/inc -I../src -Foobj/i386\ md5.c sha1.c sha256.c sha512.c fil emode.c md5.c md5.c(259) : warning C4116: unnamed type definition in parentheses sha1.c sha1.c(74) : error C2054: expected '(' to follow 'inline' sha1.c(75) : error C2085: 'set_uint32' : not in formal parameter list sha1.c(75) : error C2143: syntax error : missing ';' before '{' sha1.c(246) : warning C4116: unnamed type definition in parentheses sha256.c sha256.c(93) : error C2054: expected '(' to follow 'inline' sha256.c(94) : error C2085: 'set_uint32' : not in formal parameter list sha256.c(94) : error C2143: syntax error : missing ';' before '{' sha256.c(378) : warning C4116: unnamed type definition in parentheses [...] (more errors after this) This is caused by `inline' keyword, which should be `__inline' for MSVC. I don't see any place where this would be defined for the W32 build. Am I missing something? Christoph From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 13:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132049959019858 (code B ref 9960); Sat, 05 Nov 2011 13:27:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 13:26:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMgGU-0005AF-2m for submit@debbugs.gnu.org; Sat, 05 Nov 2011 09:26:30 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMgGQ-0005A6-MC for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 09:26:27 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LU600C00VM8YF00@a-mtaout23.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 15:23:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU600CSYVVJY910@a-mtaout23.012.net.il>; Sat, 05 Nov 2011 15:23:44 +0200 (IST) Date: Sat, 05 Nov 2011 15:22:52 +0200 From: Eli Zaretskii In-reply-to: <4EB5320F.5090800@gmail.com> X-012-Sender: halo1@inter.net.il Message-id: <83vcqyk8k3.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.7 (-) > Date: Sat, 05 Nov 2011 06:54:39 -0600 > From: Christoph Scholtes > CC: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > > I tried building with Visual Studio 2008 (Express Edition) and the build > fails: > > cl -I. -nologo -D_X86_=1 -c -Zl -Zp8 -W2 -Od -Gd -Zi > -DEMACSDEBUG -DENA > BLE_CHECKING -DXASSERTS -I"D:/devel/emacs/libs/libXpm-3.5.8/include" > -I"D:/devel > /emacs/libs/libXpm-3.5.8/src" > -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" > -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" > -I"D:/devel/emacs/libs/giflib- > 4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" > -I"D:/devel/emacs/lib > s/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" > -DHAVE_CON > FIG_H=1 -I. -I../nt/inc -I../src -Foobj/i386\ md5.c sha1.c sha256.c > sha512.c fil > emode.c > md5.c > md5.c(259) : warning C4116: unnamed type definition in parentheses > sha1.c > sha1.c(74) : error C2054: expected '(' to follow 'inline' > sha1.c(75) : error C2085: 'set_uint32' : not in formal parameter list > sha1.c(75) : error C2143: syntax error : missing ';' before '{' > sha1.c(246) : warning C4116: unnamed type definition in parentheses > sha256.c > sha256.c(93) : error C2054: expected '(' to follow 'inline' > sha256.c(94) : error C2085: 'set_uint32' : not in formal parameter list > sha256.c(94) : error C2143: syntax error : missing ';' before '{' > sha256.c(378) : warning C4116: unnamed type definition in parentheses > > [...] (more errors after this) > > This is caused by `inline' keyword, which should be `__inline' for MSVC. > I don't see any place where this would be defined for the W32 build. Am > I missing something? Does this patch give good results? === modified file 'nt/config.nt' --- nt/config.nt 2011-10-31 02:25:01 +0000 +++ nt/config.nt 2011-11-05 13:21:58 +0000 @@ -328,9 +328,13 @@ along with GNU Emacs. If not, see Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132050166823249 (code B ref 9960); Sat, 05 Nov 2011 14:02:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 14:01:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMgo0-00062v-9y for submit@debbugs.gnu.org; Sat, 05 Nov 2011 10:01:08 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMgnx-00062o-PW for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 10:01:06 -0400 Received: by ggnv1 with SMTP id v1so3389282ggn.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 06:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1CAW6MAaH0uQarpzKBlRqoTfVDQ/eseFbhYswGjTvKc=; b=Rm6xtl7JdEJfXavxyoX0Wga671iifeFpoDG6oVH9xD2APISp+ISy3fri82DkfpYa7Q p4DH4lFckGUnMFBHJQgQH2zhxC1l2DNkgyARLe9JhkFc7MPJdRmgB0oY4QseXFE0Mm8o rELXnj6sj5l6FujK+4aSEO6mIhyZ+DYScGFqQ= Received: by 10.50.189.231 with SMTP id gl7mr22709449igc.44.1320501504891; Sat, 05 Nov 2011 06:58:24 -0700 (PDT) Received: from [192.168.1.4] (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id pa4sm12679903igc.1.2011.11.05.06.58.23 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 06:58:24 -0700 (PDT) Message-ID: <4EB540F4.7080106@gmail.com> Date: Sat, 05 Nov 2011 07:58:12 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> In-Reply-To: <83vcqyk8k3.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) 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 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132050282724884 (code B ref 9960); Sat, 05 Nov 2011 14:21:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 14:20:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMh6g-0006TJ-RG for submit@debbugs.gnu.org; Sat, 05 Nov 2011 10:20:27 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMh6d-0006T9-B2 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 10:20:24 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LU600000Y3P1W00@a-mtaout21.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 16:17:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU6000NNYDF1830@a-mtaout21.012.net.il>; Sat, 05 Nov 2011 16:17:41 +0200 (IST) Date: Sat, 05 Nov 2011 16:16:40 +0200 From: Eli Zaretskii In-reply-to: <4EB540F4.7080106@gmail.com> X-012-Sender: halo1@inter.net.il Message-id: <83r51mk62f.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 05 Nov 2011 07:58:12 -0600 > From: Christoph Scholtes > CC: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > > On 11/5/2011 7:22 AM, Eli Zaretskii wrote: > > > Does this patch give good results? > > Yes. Better. Thanks. Committed. > Then it can't find a definition of `mode_t' in `strmode'. > > This patch will fix this error: > > /* Define to the equivalent of the C99 'restrict' keyword, or to > nothing if this is not supported. Do not define if restrict is > @@ -341,6 +345,13 @@ > # define restrict > #endif > > +/* Define to `int' if 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 #include #include + +/* 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__ From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 14:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: cschol2112@googlemail.com, fabrice.popineau@supelec.fr Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132050502928122 (code B ref 9960); Sat, 05 Nov 2011 14:58:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 14:57:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMhgD-0007JW-ME for submit@debbugs.gnu.org; Sat, 05 Nov 2011 10:57:09 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMhgA-0007JN-Ul for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 10:57:08 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LU600000ZVP7W00@a-mtaout21.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 16:54:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU70004M02G18A0@a-mtaout21.012.net.il>; Sat, 05 Nov 2011 16:54:17 +0200 (IST) Date: Sat, 05 Nov 2011 16:53:11 +0200 From: Eli Zaretskii In-reply-to: <83r51mk62f.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83obwqk4dk.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 05 Nov 2011 16:16:40 +0200 > From: Eli Zaretskii > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > > > +/* Define to `int' if 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 15:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.1320508486590 (code B ref 9960); Sat, 05 Nov 2011 15:55:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 15:54:46 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMiZy-00009T-2s for submit@debbugs.gnu.org; Sat, 05 Nov 2011 11:54:46 -0400 Received: from impaqm5.telefonica.net ([213.4.138.21] helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMiZt-00009H-2O for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 11:54:44 -0400 Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm5.telefonica.net with bizsmtp id tT3q1h0042kvMAa3RTry3Z; Sat, 05 Nov 2011 16:51:58 +0100 Received: from qcore ([2.138.3.15]) by IMPmailhost6.adm.correo with BIZ IMP id tTrw1h0020KS9Ve1mTrwDe; Sat, 05 Nov 2011 16:51:58 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <83obwqk4dk.fsf@gnu.org> Date: Sat, 05 Nov 2011 16:51:55 +0100 In-Reply-To: <83obwqk4dk.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Nov 2011 16:53:11 +0200") Message-ID: <87obwqbm90.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) Eli Zaretskii 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 ? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 16:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205097442498 (code B ref 9960); Sat, 05 Nov 2011 16:16:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 16:15:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMiuF-0000eF-RH for submit@debbugs.gnu.org; Sat, 05 Nov 2011 12:15:43 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMiuD-0000e6-GK for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 12:15:42 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LU7005002TYXF00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:12:00 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU7006QA3NU0800@a-mtaout20.012.net.il>; Sat, 05 Nov 2011 18:11:55 +0200 (IST) Date: Sat, 05 Nov 2011 18:10:38 +0200 From: Eli Zaretskii In-reply-to: <87obwqbm90.fsf@wanadoo.es> Message-id: <83mxcak0sh.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <83obwqk4dk.fsf@gnu.org> <87obwqbm90.fsf@wanadoo.es> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: =C3=93scar Fuentes > Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@= debbugs.gnu.org > Date: Sat, 05 Nov 2011 16:51:55 +0100 >=20 > Eli Zaretskii writes: >=20 > > 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. >=20 > Why not >=20 > #ifdef _MSC_VER > #include "sys/stat.h" > #endif >=20 > ? 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 16:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205106493798 (code B ref 9960); Sat, 05 Nov 2011 16:31:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 16:30:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMj8r-0000zD-5g for submit@debbugs.gnu.org; Sat, 05 Nov 2011 12:30:49 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMj8o-0000z5-S0 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 12:30:48 -0400 Received: by ggnv1 with SMTP id v1so3486808ggn.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 09:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=tTE+D/LGBSPT/IOST9Tv/NGSQnBFo8QM7NlTj84iTzA=; b=fHFNdjfSkwgyeW6sYjjQSG2WqZK/fWEyo/Idbw4Usjjg2zHqk7LQPxDlT/hQK/lFKP pa1p/N6OO35QSGIim5Ek35ODkMPxeGL24qKHmHT8X7HNJQiwQn/nlfWWm9oQQ/Ofxilk huSRmKvLpRtv+95LfnwqukGzrp3xxWXPN6Fo0= Received: by 10.100.230.7 with SMTP id c7mr704098anh.166.1320510485319; Sat, 05 Nov 2011 09:28:05 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id a31sm38528052ana.17.2011.11.05.09.28.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 09:28:04 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <83r51mk62f.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Nov 2011 16:16:40 +0200") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 10:27:50 -0600 Message-ID: <86wrbeo7p5.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 16:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205121056281 (code B ref 9960); Sat, 05 Nov 2011 16:56:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 16:55:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMjWL-0001dG-IH for submit@debbugs.gnu.org; Sat, 05 Nov 2011 12:55:05 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMjWI-0001d6-H8 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 12:55:04 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU7005005H33100@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:51:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU70044A5HOK2A0@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 18:51:25 +0200 (IST) Date: Sat, 05 Nov 2011 18:50:02 +0200 From: Eli Zaretskii In-reply-to: <86wrbeo7p5.fsf@googlemail.com> X-012-Sender: halo1@inter.net.il Message-id: <83k47ejyyt.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Christoph Scholtes > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 10:27:50 -0600 > > Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 17:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: cschol2112@googlemail.com, fabrice.popineau@supelec.fr Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205125296902 (code B ref 9960); Sat, 05 Nov 2011 17:03:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 17:02:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMjdB-0001nH-6j for submit@debbugs.gnu.org; Sat, 05 Nov 2011 13:02:09 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMjd9-0001nB-Lk for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 13:02:08 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU7005005MH3I00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:59:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU7003QK5UXX8J0@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 18:59:22 +0200 (IST) Date: Sat, 05 Nov 2011 18:57:57 +0200 From: Eli Zaretskii In-reply-to: <83k47ejyyt.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83hb2ijylm.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 05 Nov 2011 18:50:02 +0200 > From: Eli Zaretskii > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > > > emacsclient.obj : error LNK2001: unresolved external symbol __environ > > obj/i386/emacsclient.exe : fatal error LNK1120: 1 unresolved externals > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\ > > VC\BIN\link.EXE"' : return code '0x460' > > Stop. > > No idea about this one. Btw, if you mean this one: /* Send over our environment and current directory. */ if (!current_frame) { extern char **environ; int i; for (i = 0; environ[i]; i++) { send_to_emacs (emacs_socket, "-env "); quote_argument (emacs_socket, environ[i]); send_to_emacs (emacs_socket, " "); } then it was there since 2005, so Fabrice's build somehow succeeded to get past it. Some factor other than the declaration is at work here. Maybe I goofed in my changes in nmake.defs. Hopefully, someone or Fabrice himself will figure this out. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 17:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205139578990 (code B ref 9960); Sat, 05 Nov 2011 17:26:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 17:25:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMk0D-0002Kx-0c for submit@debbugs.gnu.org; Sat, 05 Nov 2011 13:25:57 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMk0A-0002Kn-By for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 13:25:55 -0400 Received: by ywt2 with SMTP id 2so3537148ywt.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 10:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=wI6csCtftQcpYA456vap9nrguJqA7mZArq+xY224hmc=; b=mwQZ0SQ5JBlVebRaJUhpdakU0+jL1H44Q3Z0zaP9a+MDefvhqFi0XmNvWWcC0XnL44 3HtBJ4ndx67Vl+CLc5INm+6dNiUEQhKmuFJRMHHLMCcF94+Mn3FqNbMOFpWO1lhDYA6l +0tuMBBN/WH4XVpHpSPgsWjp4CM821MLOX7GA= Received: by 10.101.152.29 with SMTP id e29mr4604720ano.46.1320513792640; Sat, 05 Nov 2011 10:23:12 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id 22sm5740608anp.12.2011.11.05.10.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 10:23:11 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <83k47ejyyt.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Nov 2011 18:50:02 +0200") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 11:22:58 -0600 Message-ID: <86sjm2o559.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 18:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132051740413843 (code B ref 9960); Sat, 05 Nov 2011 18:24:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 18:23:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMktn-0003bD-Af for submit@debbugs.gnu.org; Sat, 05 Nov 2011 14:23:23 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMktj-0003b4-7S for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 14:23:21 -0400 Received: by gye5 with SMTP id 5so3572074gye.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 11:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=qndURedU9Pa16jUNQsNIAEI64iE4+v2EK9JFTPSCtJA=; b=Eq1thY5M/1g9kSaXD1MhVP41oOu6rghbd+Nx9wpndbSd9qoLuaqmwSWonm7lq1jwOT qIZO7qhFUe9TvW4MzLLly3eT8pfdpaN+fW7vNctw903/iyNBVmLLoY79t9hSQy+M0Vng FgccUmgk4lMGpXdoWT1nOa60oFoR9MdKXPrHc= Received: by 10.236.147.114 with SMTP id s78mr26205754yhj.45.1320517237301; Sat, 05 Nov 2011 11:20:37 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id s42sm20705864yhs.0.2011.11.05.11.20.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 11:20:36 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <86sjm2o559.fsf@googlemail.com> (Christoph Scholtes's message of "Sat, 05 Nov 2011 11:22:58 -0600") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 12:20:22 -0600 Message-ID: <86obwqo2hl.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) Christoph Scholtes 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? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132052190820530 (code B ref 9960); Sat, 05 Nov 2011 19:39:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 19:38:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMm4R-0005L5-Nj for submit@debbugs.gnu.org; Sat, 05 Nov 2011 15:38:28 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMm4M-0005Kt-Hg for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 15:38:23 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU700600D2IKR00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 21:35:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU70051VD3DB9L0@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 21:35:39 +0200 (IST) Date: Sat, 05 Nov 2011 21:33:51 +0200 From: Eli Zaretskii In-reply-to: <86obwqo2hl.fsf@googlemail.com> X-012-Sender: halo1@inter.net.il Message-id: <83d3d6jrds.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Christoph Scholtes > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 12:20:22 -0600 > > nmake does not like the relative path invocation of make-docfile with > forward slashes (makefile.w32-in, l.235) > > "../lib-src/$(BLD)/make-docfile" -d . -g $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp Why?? even cmd.exe is in peace with forward slashes, as long as they are in quotes. What is the error message? are you sure the problem is with forward slashes, and not with something else? If the problem is with forward slashes, how come invocations of make-docfile and other commands in lib-src/makefile.w32-in, which also use forward slashes, did work? Are you sure you are using nmake that came with the version of Studio that you are using to compile, and not some ancient version? > If I hardcode this to > > "..\\lib-src\\obj\\i386\\make-docfile" -d . -g $(SOME_MACHINE_OBJECTS) > $(obj) > gl-tmp > > it works. We might have to use forward slashes here and change BLD accordingly? That way lies madness. This worked with nmake for ages. We cannot possibly change all slashes in all the makefile's, I don't even know any portable method of doing that, without breaking builds with a Unixy shell, which we also support. We must to get to the bottom of this problem. > d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2061: syntax er > ror : identifier 'cons_to_signed' > d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er > ror : ';' > d:\devel\emacs\emacs-bzr\trunk_jenkins\src\lisp.h(2499) : error C2059: syntax er > ror : 'type' Is the problem with Lisp_Object or with intmax_t? (You can find out if you change each one to some standard type, like `int'.) > emacs.c(537) : error C2059: syntax error : '<<' > emacs.c(537) : error C2059: syntax error : 'constant' > emacs.c(537) : error C2059: syntax error : ')' > emacs.c(545) : error C2059: syntax error : '<<' > emacs.c(545) : error C2059: syntax error : 'constant' > emacs.c(545) : error C2059: syntax error : ')' > emacs.c(1992) : error C2059: syntax error : '<<' > emacs.c(1992) : error C2059: syntax error : 'constant' > emacs.c(1992) : error C2059: syntax error : ')' > emacs.c(2130) : error C2059: syntax error : '<<' > emacs.c(2130) : error C2059: syntax error : 'constant' > emacs.c(2130) : error C2059: syntax error : ')' > emacs.c(2337) : error C2059: syntax error : '<<' > emacs.c(2337) : error C2059: syntax error : 'constant' > emacs.c(2337) : error C2059: syntax error : ')' > emacs.c(2352) : error C2059: syntax error : '<<' > emacs.c(2352) : error C2059: syntax error : 'constant' > emacs.c(2352) : error C2059: syntax error : ')' These all are about DEFUN. The only thing I changed in the definition provided by Fabrice was to add "static" here: +#define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc) \ + Lisp_Object fnname DEFUN_ARGS_ ## maxargs ; \ + static DECL_ALIGN (struct Lisp_Subr, sname) = \ ^^^^^^ Please remove the "static" part and see if that helps. > I am starting to wonder how Fabrice ever got this to compile. Are all of > these errors due to changes made between his original patch and the > current trunk state? Yes. You now have an idea how many water goes under the bridge in one year of Emacs development. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 20:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132052531525354 (code B ref 9960); Sat, 05 Nov 2011 20:36:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 20:35:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMmxO-0006at-WE for submit@debbugs.gnu.org; Sat, 05 Nov 2011 16:35:15 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMmxM-0006aj-Fy for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 16:35:13 -0400 Received: by ggnv1 with SMTP id v1so3637871ggn.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 13:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=npxPxZSePYluUaH/V9zdZAqYqalH+u8nBIPZU0PrurI=; b=hziTxdf4i7cExXDJFWqRsYSaH88yr/wOWikpZ0FsfLJ+t7+dsK+upOmP8si2HvfZKx s+yV1/bxUHgd0FMiEhFkUibQFtFk77CLEEkrrCIdzL4ibIFB+jkRNVI4E5TIedze8zo3 QaHM48qyyVw8H4uN5JLSCvSM+TMW+ih//qlQo= Received: by 10.236.173.131 with SMTP id v3mr27962490yhl.112.1320525149994; Sat, 05 Nov 2011 13:32:29 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id y71sm21085028yhh.6.2011.11.05.13.32.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 13:32:29 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <86obwqo2hl.fsf@googlemail.com> (Christoph Scholtes's message of "Sat, 05 Nov 2011 12:20:22 -0600") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 14:32:15 -0600 Message-ID: <86ipmynwds.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) Christoph Scholtes 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 20:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132052570326013 (code B ref 9960); Sat, 05 Nov 2011 20:42:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 20:41:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMn3e-0006lV-Tx for submit@debbugs.gnu.org; Sat, 05 Nov 2011 16:41:43 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMn3b-0006lL-AN for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 16:41:40 -0400 Received: by ywt2 with SMTP id 2so3656073ywt.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 13:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=YAm3eXjtvTl+nEzlg+96hW30+HeqtvTL38V6vRFqBvE=; b=ZbjL0kzCB/9PxebAeGnAOScN003r9FRVJpLXQ9z7Bsbx8/1zknXNgB0pm5L13LYOzp Egx2aHNj6icXlk6nykHFNueROE16W0RgNhWRKb9ezGeELTgNhtRAHIY6pXJPEhS/kY8f XkxKjwxOhOWZB112Tyqci6xGw2E0PbjPUXGss= Received: by 10.236.124.105 with SMTP id w69mr27462968yhh.2.1320525536645; Sat, 05 Nov 2011 13:38:56 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id 4sm40187037ano.9.2011.11.05.13.38.54 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 13:38:56 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <83d3d6jrds.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Nov 2011 21:33:51 +0200") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 14:38:41 -0600 Message-ID: <86ehxmnw32.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) Eli Zaretskii 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. ;) From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 21:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132052788629141 (code B ref 9960); Sat, 05 Nov 2011 21:19:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 21:18:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMncs-0007Zx-Ba for submit@debbugs.gnu.org; Sat, 05 Nov 2011 17:18:06 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMncp-0007Zp-K0 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 17:18:05 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LU700100HLSCI00@a-mtaout21.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 23:13:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU7001NYHN26D90@a-mtaout21.012.net.il>; Sat, 05 Nov 2011 23:13:51 +0200 (IST) Date: Sat, 05 Nov 2011 23:11:49 +0200 From: Eli Zaretskii In-reply-to: <86ehxmnw32.fsf@googlemail.com> X-012-Sender: halo1@inter.net.il Message-id: <83aa8ajmui.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> <86ehxmnw32.fsf@googlemail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Christoph Scholtes > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 14:38:41 -0600 > > Eli Zaretskii 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? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 21:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132052877030426 (code B ref 9960); Sat, 05 Nov 2011 21:33:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 21:32:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMnr4-0007ua-6L for submit@debbugs.gnu.org; Sat, 05 Nov 2011 17:32:50 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMnr0-0007uQ-MQ for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 17:32:44 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LU700800IB9IX00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 23:29:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU7008ZRIDN0VC0@a-mtaout20.012.net.il>; Sat, 05 Nov 2011 23:29:48 +0200 (IST) Date: Sat, 05 Nov 2011 23:27:44 +0200 From: Eli Zaretskii In-reply-to: <86ipmynwds.fsf@googlemail.com> X-012-Sender: halo1@inter.net.il Message-id: <838vnujm3z.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Christoph Scholtes > Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 14:32:15 -0600 > > Christoph Scholtes 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.) From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 22:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205310391156 (code B ref 9960); Sat, 05 Nov 2011 22:11:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 22:10:39 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMoRi-0000Ib-T9 for submit@debbugs.gnu.org; Sat, 05 Nov 2011 18:10:39 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMoRg-0000IT-6q for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:10:37 -0400 Received: by gye5 with SMTP id 5so3700985gye.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 15:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VHuERBeI+67PCXHVeDl/DHqQxx3FGKFxcNXlpuMZK+s=; b=B7vphkhgeM02pPU4NxXMslw+pJq53iUPbVIEdoO06QRaTdYHgcgSaBLvLORWX0Sh24 obraQmL/JhNdGvTUfrd5fsQh8P7W2/ZDWpNG2b6MDl4jDBZ+VfyN3GhkzLRySDqAvaAl g4CE/ivT831q5KDSTkxnoCM8cjcSCJt4mFmfc= Received: by 10.50.169.99 with SMTP id ad3mr25923390igc.6.1320530873322; Sat, 05 Nov 2011 15:07:53 -0700 (PDT) Received: from [192.168.1.4] (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id pa4sm13651768igc.1.2011.11.05.15.07.52 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 15:07:52 -0700 (PDT) Message-ID: <4EB5B3AB.1030601@gmail.com> Date: Sat, 05 Nov 2011 16:07:39 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> <86ehxmnw32.fsf@googlemail.com> <83aa8ajmui.fsf@gnu.org> In-Reply-To: <83aa8ajmui.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) 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 `..'. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 22:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205314851830 (code B ref 9960); Sat, 05 Nov 2011 22:19:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 22:18:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMoYu-0000TS-OA for submit@debbugs.gnu.org; Sat, 05 Nov 2011 18:18:05 -0400 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMoYs-0000TL-Ql for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:18:03 -0400 Received: by iaeo4 with SMTP id o4so4170545iae.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 15:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0XVZiCNmRK73yCx+mp1U76FbQcaJM3uWzrIcKZpiOSs=; b=IlQugwtTqWsINiQqZgs7BXHgJsraA1HfgYZtW89dbPPMmMyHl3pxunTuyc3/AsPSNG PWj3/xf4KB7XBLCxO/3EVX1eV0yO0vzqdBPp9OwAbTFRh7F/tCPE0Qc2cSM8Nk/K34p6 pee4WKdplaMTYIJQJ4QHJlMwKcDaQGcmCKC9s= Received: by 10.42.176.130 with SMTP id be2mr1108887icb.11.1320531319873; Sat, 05 Nov 2011 15:15:19 -0700 (PDT) Received: from [192.168.1.4] (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id ge16sm29990044ibb.2.2011.11.05.15.15.18 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 15:15:19 -0700 (PDT) Message-ID: <4EB5B56A.5050600@gmail.com> Date: Sat, 05 Nov 2011 16:15:06 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> <86ehxmnw32.fsf@googlemail.com> <83aa8ajmui.fsf@gnu.org> <4EB5B3AB.1030601@gmail.com> In-Reply-To: <4EB5B3AB.1030601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) 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... From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 22:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205319242435 (code B ref 9960); Sat, 05 Nov 2011 22:26:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 22:25:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMofz-0000dE-V5 for submit@debbugs.gnu.org; Sat, 05 Nov 2011 18:25:24 -0400 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMofx-0000d6-Lp for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:25:22 -0400 Received: by iaeo4 with SMTP id o4so4175498iae.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 15:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mWQKq/OKcA9Hp03u+rvIpUxncaWVMyoDwiSMW+8lsp0=; b=AQC+oX5Vy8ruLRa33KFxe2jf3yColH/xvWVHMbEJnL4ea/n905DCmm2kl+saRXLB4n pyO2DGCB6YC/+BF1vx3sYmFw7PRP+SY+RGTLUkTlQC8Ddax/tLqPauuLJYw/XxA4ln3X TILAn5q1J/xBA1lE897MJ3SMLxWixz1MBYpbI= Received: by 10.42.151.68 with SMTP id d4mr29358841icw.36.1320531758912; Sat, 05 Nov 2011 15:22:38 -0700 (PDT) Received: from [192.168.1.4] (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id ge16sm30015384ibb.2.2011.11.05.15.22.38 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 15:22:38 -0700 (PDT) Message-ID: <4EB5B721.5040409@gmail.com> Date: Sat, 05 Nov 2011 16:22:25 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> <86ehxmnw32.fsf@googlemail.com> <83aa8ajmui.fsf@gnu.org> <4EB5B3AB.1030601@gmail.com> <4EB5B56A.5050600@gmail.com> In-Reply-To: <4EB5B56A.5050600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2011 22:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205320002552 (code B ref 9960); Sat, 05 Nov 2011 22:27:02 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Nov 2011 22:26:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMohD-0000f7-Hr for submit@debbugs.gnu.org; Sat, 05 Nov 2011 18:26:39 -0400 Received: from mail-qy0-f172.google.com ([209.85.216.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMohB-0000f0-OJ for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 18:26:38 -0400 Received: by qyl16 with SMTP id 16so1805705qyl.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 15:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=pqDp+8jTTPnIluI4zLaDgKAiNRT4IfZQY1iymCnhLNU=; b=wjhO5Kjv+CnWRrw25dR5pjCRvzuq0vn8k30KTvVwWpcs5MEoF1ho1CG+oFlQoViZZf QqlHCEJLr001oEpYINxQ4Ccm5ao3j/VszzJmdaU/6vTjnJgQ6JkE7E6SEhISpoAeywbz 3dWHt3PMA7FG2/B9MGlcczKJbwTzC/mr68ABQ= Received: by 10.229.216.200 with SMTP id hj8mr2449277qcb.96.1320531834813; Sat, 05 Nov 2011 15:23:54 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id do8sm14512079qab.17.2011.11.05.15.23.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 15:23:54 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <838vnujm3z.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Nov 2011 23:27:44 +0200") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 16:23:40 -0600 Message-ID: <868vnunr83.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) Eli Zaretskii 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]; From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 01:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132054153718227 (code B ref 9960); Sun, 06 Nov 2011 01:06:01 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 01:05:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMrB2-0004jv-6p for submit@debbugs.gnu.org; Sat, 05 Nov 2011 21:05:36 -0400 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMpxJ-0002SV-Ea for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 19:47:22 -0400 Received: by bkbzv15 with SMTP id zv15so2419059bkb.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 16:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=elhwYJrbhguuSVXdh6RfS5Xoof6uFbE34Wc9G1km4sM=; b=TIZqPgiF4OYRdsphEMYNJpdsrryHOZIG7LaHNhYY1yXwG7+HEXlW7SVB0PmPCdf42k afjDWFGr4FWaEcytLiX01OabHzvZ1GuOl/f4yLLNrG/JO21mv31fI442f+ATLD5vCMFX FCAOMTQHauQyWwxG6KFzfYyO9pIoJ44xAeFtw= Received: by 10.204.37.79 with SMTP id w15mr15801536bkd.4.1320536677711; Sat, 05 Nov 2011 16:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 5 Nov 2011 16:44:15 -0700 (PDT) In-Reply-To: <83zkgakdby.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> From: Fabrice Popineau Date: Sun, 6 Nov 2011 00:44:15 +0100 X-Google-Sender-Auth: BWG0JB8Mx3CubSAquT8rd_ycDpc Message-ID: Content-Type: multipart/alternative; boundary=bcaec554d32c96808304b10567fa X-Spam-Score: -3.6 (---) X-Mailman-Approved-At: Sat, 05 Nov 2011 21:05:35 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --bcaec554d32c96808304b10567fa Content-Type: text/plain; charset=ISO-8859-1 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 --bcaec554d32c96808304b10567fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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
=
--bcaec554d32c96808304b10567fa-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 01:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132054438424077 (code B ref 9960); Sun, 06 Nov 2011 01:54:02 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 01:53:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMruy-0006GI-FO for submit@debbugs.gnu.org; Sat, 05 Nov 2011 21:53:04 -0400 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMruv-0006Fx-Oe for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 21:53:02 -0400 Received: by gye5 with SMTP id 5so3805332gye.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 18:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=ayYseOXh//bjYzPxp/tR/atEX7b3B8mGcDnWLA8Gn+c=; b=tob4ClUmqjGdar9MLoDj1Tuo/Vh4udj7SMeVoZmumciU9WjDLgkcIuJNe8DhNUcMN5 xK1BFxTNUDS5OSeXXrnS62r7Cs2DXy7IAv5MIoiMM+br+BVcR4O4Ke5E6+fmzWAvZN5U QYPxnM/8H8T8kCPx/SuLSuR3Ekr9pZrjn7e6Y= Received: by 10.236.122.237 with SMTP id t73mr23333765yhh.99.1320544217811; Sat, 05 Nov 2011 18:50:17 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id 38sm28678157anz.8.2011.11.05.18.50.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 18:50:16 -0700 (PDT) From: Christoph Scholtes In-Reply-To: <868vnunr83.fsf@googlemail.com> (Christoph Scholtes's message of "Sat, 05 Nov 2011 16:23:40 -0600") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <868vnunr83.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 19:50:01 -0600 Message-ID: <86hb2iow8m.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) Christoph Scholtes 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 03:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205511635136 (code B ref 9960); Sun, 06 Nov 2011 03:47:02 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 03:46:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMtgH-0001Kc-IO for submit@debbugs.gnu.org; Sat, 05 Nov 2011 23:46:02 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMtgE-0001KE-D0 for 9960@debbugs.gnu.org; Sat, 05 Nov 2011 23:45:59 -0400 Received: by ggnv1 with SMTP id v1so3840275ggn.3 for <9960@debbugs.gnu.org>; Sat, 05 Nov 2011 20:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=xURxYs//FVkcFiUmYGFpDabmEZRdVPqYh4zl5oizs1U=; b=jCPgq+6uRTvkPkWbXfLV7qHTyIY4LbLFykUWMEjqNmwAtHZ8xHmTHxQlWko+rn/lXb ZUboe5ZQgQlPBOBqtFzAjg2efkXhz7e40Jn7cJkj6Z3Rjmj92PH0o9y4e04nY00DrtT3 rfXBQQQAEtUdM1ctNSPHmQQBT87+ZcQMBPkqU= Received: by 10.236.77.163 with SMTP id d23mr27520291yhe.34.1320550994151; Sat, 05 Nov 2011 20:43:14 -0700 (PDT) Received: from MARVIN (71-212-156-190.hlrn.qwest.net. [71.212.156.190]) by mx.google.com with ESMTPS id 32sm23275293anu.10.2011.11.05.20.43.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 20:43:13 -0700 (PDT) From: Christoph Scholtes In-Reply-To: (Fabrice Popineau's message of "Sun, 6 Nov 2011 00:44:15 +0100") References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) Date: Sat, 05 Nov 2011 21:42:58 -0600 Message-ID: <86d3d5q5kt.fsf@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) Fabrice Popineau 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 04:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205524167509 (code B ref 9960); Sun, 06 Nov 2011 04:07:01 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 04:06:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMu0V-0001x4-Qx for submit@debbugs.gnu.org; Sun, 06 Nov 2011 00:06:56 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMu0S-0001wv-BK for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 00:06:53 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LU800B000LRFU00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 06:04:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU800B5M0MV6Q70@a-mtaout20.012.net.il>; Sun, 06 Nov 2011 06:04:07 +0200 (IST) Date: Sun, 06 Nov 2011 06:02:04 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834nyhkif7.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Sun, 6 Nov 2011 00:44:15 +0100 > Cc: 9960@debbugs.gnu.org > > Ouch. I'm not up to speed to answer all of this. Eventually, it is best if you try the latest trunk, and deal only with the problems that are left. > (Spent the day in a plane to go to some conference near Miami). > I should be able to check with my copy in a couple of days. Thanks, we all have our lives. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 04:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13205525097700 (code B ref 9960); Sun, 06 Nov 2011 04:09:02 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 04:08:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMu20-000208-Ip for submit@debbugs.gnu.org; Sun, 06 Nov 2011 00:08:29 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMu1y-0001zz-Ip for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 00:08:27 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LU800B000LRFU00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 06:05:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU800BDJ0OO6A70@a-mtaout20.012.net.il>; Sun, 06 Nov 2011 06:05:13 +0200 (IST) Date: Sun, 06 Nov 2011 06:03:10 +0200 From: Eli Zaretskii In-reply-to: <4EB5B721.5040409@gmail.com> X-012-Sender: halo1@inter.net.il Message-id: <8339e1kidd.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <83d3d6jrds.fsf@gnu.org> <86ehxmnw32.fsf@googlemail.com> <83aa8ajmui.fsf@gnu.org> <4EB5B3AB.1030601@gmail.com> <4EB5B56A.5050600@gmail.com> <4EB5B721.5040409@gmail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 05 Nov 2011 16:22:25 -0600 > From: Christoph Scholtes > CC: 9960@debbugs.gnu.org > > "$(THISDIR)/../lib-src/$(BLD)/make-docfile" -d . -g > $(SOME_MACHINE_OBJECTS) $(obj) > gl-tmp > > This works. Great. Does it need to be $(THISDIR) or can it be a literal "."? The latter is shorter and easier to understand, if it works. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 05:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132055803119073 (code B ref 9960); Sun, 06 Nov 2011 05:41:01 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 05:40:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMvT4-0004xa-SF for submit@debbugs.gnu.org; Sun, 06 Nov 2011 01:40:31 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMvT2-0004xR-Lv for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 01:40:29 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RMvQO-00010x-3R; Sun, 06 Nov 2011 01:37:44 -0400 Date: Sun, 06 Nov 2011 01:37:44 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <868vnunr83.fsf@googlemail.com> (message from Christoph Scholtes on Sat, 05 Nov 2011 16:23:40 -0600) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <868vnunr83.fsf@googlemail.com> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Christoph Scholtes > Cc: 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 16:23:40 -0600 > > Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 05:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132055863020480 (code B ref 9960); Sun, 06 Nov 2011 05:51:01 +0000 Received: (at 9960) by debbugs.gnu.org; 6 Nov 2011 05:50:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMvcj-0005KG-OM for submit@debbugs.gnu.org; Sun, 06 Nov 2011 01:50:30 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMvcg-0005K4-TE for 9960@debbugs.gnu.org; Sun, 06 Nov 2011 01:50:27 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RMva2-0001aT-Nv; Sun, 06 Nov 2011 01:47:42 -0400 Date: Sun, 06 Nov 2011 01:47:42 -0400 Message-Id: From: Eli Zaretskii In-reply-to: <86hb2iow8m.fsf@googlemail.com> (message from Christoph Scholtes on Sat, 05 Nov 2011 19:50:01 -0600) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <868vnunr83.fsf@googlemail.com> <86hb2iow8m.fsf@googlemail.com> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Christoph Scholtes > Cc: 9960@debbugs.gnu.org > Date: Sat, 05 Nov 2011 19:50:01 -0600 > > I found this old thread dealing with MSVC problems: > http://old.nabble.com/Compilation-problems-with-latest-MSVC-td8040440.html > > I undef'ed HAVE_TZNAME and it linked, but then crashed when dumping with > the following error: > > Dumping from obj/i386/temacs.bin > to obj/i386/temacs.exe > "D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/temacs.exe" -batch > -l loadup dump > NMAKE : fatal error U1077: 'D:\devel\emacs\emacs-bzr\trunk_jenkins\src/obj/i386/temacs.exe' : return code '0xc0000135' > Stop. According to my references, 0xc0000135 means "DLL not found". Can you try to find out which DLL is that? Perhaps run `depends' on temacs.exe and see which DLLs are flagged as not available (note that 1 or 2 are normally absent, you can google them to find out). From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2011 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Christoph Scholtes , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13206825874831 (code B ref 9960); Mon, 07 Nov 2011 16:17:01 +0000 Received: (at 9960) by debbugs.gnu.org; 7 Nov 2011 16:16:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNRs2-0001Fs-Vd for submit@debbugs.gnu.org; Mon, 07 Nov 2011 11:16:27 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNRrz-0001Fg-CG for 9960@debbugs.gnu.org; Mon, 07 Nov 2011 11:16:25 -0500 Received: by bkbzv15 with SMTP id zv15so3311200bkb.3 for <9960@debbugs.gnu.org>; Mon, 07 Nov 2011 08:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=mvzWNVwunun52Odl7wpfcnRpQeiNrXZAVcOxCJrpvlQ=; b=OLvG3PccgT0N/4wyOG7MkuVWOrLQoddFDX+oHK1F9R3SSZTj8+LGSK1IH0cEdF1dN9 lnaAMweoEu2iTzdrPSM9Trb3hAhAhdCci5gOG/62TvO0LuAsU2/KxY2z0UgIg70IMC3c jl2Gy5Oc12tSTy+R16B9p1ZhhVBQvOv6Tqp4E= Received: by 10.204.37.79 with SMTP id w15mr20103469bkd.4.1320682410185; Mon, 07 Nov 2011 08:13:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Mon, 7 Nov 2011 08:13:09 -0800 (PST) In-Reply-To: <838vnujm3z.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> From: Fabrice Popineau Date: Mon, 7 Nov 2011 17:13:09 +0100 X-Google-Sender-Auth: MzHTlR8o7cDJwKa8cfTotMLkasI Message-ID: Content-Type: multipart/alternative; boundary=bcaec554d32ceb94fb04b12755c1 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --bcaec554d32ceb94fb04b12755c1 Content-Type: text/plain; charset=ISO-8859-1 > > > Christoph Scholtes 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<
> Christoph Scholtes <= cschol2112@googlemail.com> writes:
>
> > Then we get to emacs.c:
> > emacs.c(537) : error C2059: syntax error : '<<'
> > emacs.c(537) : error C2059: syntax error : 'constant'
> > emacs.c(537) : error C2059: syntax error : ')'
>
> cl.exe does not like the shift operator in this statement:
>
> static int __declspec(align(1 << 3)) test =3D 1;

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

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

What about an intermediate macro, as in

=A0#define FOO (1 << GCTYPEBITS)
=A0static int __declspec(align(FOO)) test =3D 1;

Ok. I have to admit that it does not work this way with msvc. Actuall= y, I can't find a way to make
cl.exe compute the (1<< G= CTYPEBITS) before giving it to the align declaration. At least not with the= current release of cl.exe (16.00.40219.01).=A0I 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= ) =3D=3D 2
#define ALIGN_GCTYPEBITS 2
#elif (1<<G= CTYPEBITS) =3D=3D 4
#define ALIGN_GCTYPEBITS 4
#elif (1<<GCTYPEBITS) =3D= =3D 8
#define ALIGN_GCTYPEBITS 8
#else
#error= Define ALIGN_GCTYPEBITS
#endif

static i= nt __declspec(align(ALIGN_GCTYPEBITS)) test =3D 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 i= t, I'm using my own version every day :-) )

Fabrice
--bcaec554d32ceb94fb04b12755c1-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2011 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13206854148832 (code B ref 9960); Mon, 07 Nov 2011 17:04:02 +0000 Received: (at 9960) by debbugs.gnu.org; 7 Nov 2011 17:03:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNSbd-0002IO-CL for submit@debbugs.gnu.org; Mon, 07 Nov 2011 12:03:33 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNSba-0002ID-IU for 9960@debbugs.gnu.org; Mon, 07 Nov 2011 12:03:32 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUA00F00V5AC400@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Mon, 07 Nov 2011 18:59:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUA00AAVV7LH631@a-mtaout20.012.net.il>; Mon, 07 Nov 2011 18:59:46 +0200 (IST) Date: Mon, 07 Nov 2011 18:57:44 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83ty6fj2ev.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Mon, 7 Nov 2011 17:13:09 +0100 > Cc: Christoph Scholtes , 9960@debbugs.gnu.org > > > #define FOO (1 << GCTYPEBITS) > > static int __declspec(align(FOO)) test = 1; > > > Ok. I have to admit that it does not work this way with msvc. Actually, I > can't find a way to make > cl.exe compute the (1<< GCTYPEBITS) before giving it to the align > declaration. At least not with the current release of cl.exe > (16.00.40219.01). I can't check about the previous ones I may have used. > [...] > and yes I compiled it, I'm using my own version every day :-) So you are saying that __declspec(align(1 << GCTYPEBITS)) surely did work for you with some other version of MSVC? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2011 17:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13206856999232 (code B ref 9960); Mon, 07 Nov 2011 17:09:02 +0000 Received: (at 9960) by debbugs.gnu.org; 7 Nov 2011 17:08:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNSgE-0002Or-Pe for submit@debbugs.gnu.org; Mon, 07 Nov 2011 12:08:18 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNSgC-0002Oj-L0 for 9960@debbugs.gnu.org; Mon, 07 Nov 2011 12:08:17 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LUA00300VE3AV00@a-mtaout23.012.net.il> for 9960@debbugs.gnu.org; Mon, 07 Nov 2011 19:05:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUA003TSVGV9O30@a-mtaout23.012.net.il>; Mon, 07 Nov 2011 19:05:20 +0200 (IST) Date: Mon, 07 Nov 2011 19:03:18 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83sjlzj25l.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.7 (-) > From: Fabrice Popineau > Date: Mon, 7 Nov 2011 17:13:09 +0100 > Cc: Christoph Scholtes , 9960@debbugs.gnu.org > > Our best bet is to use a construction like : > > #define GCTYPEBITS 4 > #if (1< #define ALIGN_GCTYPEBITS 2 > #elif (1< #define ALIGN_GCTYPEBITS 4 > #elif (1< #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? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: fix for Bug#9772 should also help fix Bug#9960 References: <8339e2lsu7.fsf@gnu.org> In-Reply-To: <8339e2lsu7.fsf@gnu.org> Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Nov 2011 06:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132073480824429 (code B ref 9960); Tue, 08 Nov 2011 06:47:01 +0000 Received: (at 9960) by debbugs.gnu.org; 8 Nov 2011 06:46:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNfSI-0006Lw-8W for submit@debbugs.gnu.org; Tue, 08 Nov 2011 01:46:47 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNfSC-0006Ll-5H for 9960@debbugs.gnu.org; Tue, 08 Nov 2011 01:46:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E957539E800C for <9960@debbugs.gnu.org>; Mon, 7 Nov 2011 22:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1RYXqCDDmc8 for <9960@debbugs.gnu.org>; Mon, 7 Nov 2011 22:43:41 -0800 (PST) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 8A52F39E8007 for <9960@debbugs.gnu.org>; Mon, 7 Nov 2011 22:43:41 -0800 (PST) Message-ID: <4EB8CFA2.8050809@cs.ucla.edu> Date: Mon, 07 Nov 2011 22:43:46 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060707080900070208090306" X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) This is a multi-part message in MIME format. --------------060707080900070208090306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. --------------060707080900070208090306 Content-Type: text/plain; name="stdalign1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="stdalign1.txt" IyBCYXphYXIgbWVyZ2UgZGlyZWN0aXZlIGZvcm1hdCAyIChCYXphYXIgMC45MCkKIyByZXZp c2lvbl9pZDogZWdnZXJ0QGNzLnVjbGEuZWR1LTIwMTExMTA4MDYzNTM3LWRqejRha2hwazRr cG9heTEKIyB0YXJnZXRfYnJhbmNoOiBienIrc3NoOi8vZWdnZXJ0QGJ6ci5zYXZhbm5haC5n bnUub3JnL2VtYWNzL3RydW5rCiMgdGVzdGFtZW50X3NoYTE6IDc3YTUwZTE1NGI4M2M5NTY1 Y2MxNDJmNTc2ZjgxNDE3ZjY3YjdlOWQKIyB0aW1lc3RhbXA6IDIwMTEtMTEtMDcgMjI6MzU6 NDQgLTA4MDAKIyBiYXNlX3JldmlzaW9uX2lkOiBtb25uaWVyQGlyby51bW9udHJlYWwuY2Et MjAxMTExMDgwMjU3NTktXAojICAgZDV1MGFnNGhkaWUyN2xjegojIAojIEJlZ2luIHBhdGNo Cj09PSBtb2RpZmllZCBmaWxlICcuYnpyaWdub3JlJwotLS0gLmJ6cmlnbm9yZQkyMDExLTA5 LTI5IDE0OjE5OjExICswMDAwCisrKyAuYnpyaWdub3JlCTIwMTEtMTAtMTcgMDE6MjI6MTkg KzAwMDAKQEAgLTUzLDYgKzUzLDcgQEAKIGxpYi9jKytkZWZzLmgKIGxpYi9nZXRvcHQuaAog bGliL2ludHR5cGVzLmgKK2xpYi9zdGRhbGlnbi5oCiBsaWIvc3RkYm9vbC5oCiBsaWIvc3Rk aW8uaAogbGliL3N0ZGludC5oCgo9PT0gbW9kaWZpZWQgZmlsZSAnQ2hhbmdlTG9nJwotLS0g Q2hhbmdlTG9nCTIwMTEtMTEtMDUgMTE6MzQ6NTYgKzAwMDAKKysrIENoYW5nZUxvZwkyMDEx LTExLTA4IDAxOjA3OjE4ICswMDAwCkBAIC0xLDMgKzEsMjAgQEAKKzIwMTEtMTEtMDggIFBh dWwgRWdnZXJ0ICA8ZWdnZXJ0QGNzLnVjbGEuZWR1PgorCisJVXNlIEdudWxpYiBzdGRhbGln biBtb2R1bGUgKEJ1ZyM5NzcyLCBCdWcjOTk2MCkuCisJVGhpcyBzaG91bGQgaW1wcm92ZSBw b3J0YWJpbGl0eSBvZiBtYWNyb3MgbGlrZSBhbGlnbm9mIGFuZCBERUNMX0FMSUdOLgorCSog bGliL3N0ZGFsaWduLmluLmgsIG00L3N0ZGFsaWduLm00OiBOZXcgZmlsZXMsIGZyb20gZ251 bGliLgorCSogLmJ6cmlnbm9yZTogQWRkIGxpYi9zdGRhbGlnbi5oLgorCSogTWFrZWZpbGUu aW4gKEdOVUxJQl9NT0RVTEVTKTogQWRkIHN0ZGFsaWduLgorCSogY29uZmlnLmJhdDogRG8g bm90IHNldCBOT19ERUNMX0FMSUdOOyBubyBsb25nZXIgbmVlZGVkLgorCUNvcHkgbGliL3N0 ZGFsaWduLmluLmggdG8gbGliL3N0ZGFsaWduLmluLWggYXMgbmVlZGVkLgorCSogY29uZmln dXJlLmluIChIQVZFX0FUVFJJQlVURV9BTElHTkVEKTogUmVtb3ZlIHRoZSBjb2RlIHRoYXQK KwlmaWRkbGVzIHdpdGggdGhpcywgYXMgZ251bGliIG5vdyBkb2VzIHRoaXMgZm9yIHVzLgor CSogbGliL2dudWxpYi5taywgbGliL21kNS5jLCBsaWIvc2hhMS5jLCBsaWIvc2hhMjU2LmMs IGxpYi9zaGE1MTIuYzoKKwkqIG00L2dsLWNvbXAubTQsIG00L3B0aHJlYWRfc2lnbWFzay5t NDogTWVyZ2UgZnJvbSBnbnVsaWIuCisKKwkqIGRvYy9taXNjL3RleGluZm8udGV4LCBsaWIv Z2V0dGV4dC5oLCBsaWIvZ251bGliLm1rLCBsaWIvc3RkbGliLmluLmg6CisJKiBtNC9pbmNs dWRlX25leHQubTQsIG00L3N0ZGxpYl9oLm00OiBNZXJnZSBmcm9tIGdudWxpYi4KKwogMjAx MS0xMS0wNSAgRWxpIFphcmV0c2tpaSAgPGVsaXpAZ251Lm9yZz4KIAogCSogbGliL21ha2Vm aWxlLnczMi1pbiAoRlJDKTogTmV3IGR1bW15IHRhcmdldC4KCj09PSBtb2RpZmllZCBmaWxl ICdNYWtlZmlsZS5pbicKLS0tIE1ha2VmaWxlLmluCTIwMTEtMDktMjYgMjE6MzA6MTggKzAw MDAKKysrIE1ha2VmaWxlLmluCTIwMTEtMTAtMTcgMDE6MjI6MTkgKzAwMDAKQEAgLTMzNyw3 ICszMzcsNyBAQAogICBkdXAyIFwKICAgZmlsZW1vZGUgZ2V0bG9hZGF2ZyBnZXRvcHQtZ251 IGlnbm9yZS12YWx1ZSBpbnRwcm9wcyBsc3RhdCBcCiAgIG1rdGltZSBwdGhyZWFkX3NpZ21h c2sgcmVhZGxpbmsgXAotICBzb2NrbGVuIHN0ZGFyZyBzdGRpbyBzdHJmdGltZSBzdHJ0b2lt YXggc3RydG91bWF4IHN5bWxpbmsgc3lzX3N0YXQKKyAgc29ja2xlbiBzdGRhbGlnbiBzdGRh cmcgc3RkaW8gc3RyZnRpbWUgc3RydG9pbWF4IHN0cnRvdW1heCBzeW1saW5rIHN5c19zdGF0 CiBHTlVMSUJfVE9PTF9GTEFHUyA9IFwKICAtLWF2b2lkPW1zdmMtaW52YWwgLS1hdm9pZD1t c3ZjLW5vdGhyb3cgLS1hdm9pZD1wYXRobWF4IFwKICAtLWF2b2lkPXJhaXNlIC0tYXZvaWQ9 dGhyZWFkbGliIFwKCj09PSBtb2RpZmllZCBmaWxlICdjb25maWcuYmF0JwotLS0gY29uZmln LmJhdAkyMDExLTEwLTMxIDE3OjQ5OjEwICswMDAwCisrKyBjb25maWcuYmF0CTIwMTEtMTEt MDEgMDU6MDM6NTYgKzAwMDAKQEAgLTE2MywyMiArMTYzLDYgQEAKIGlmIGV4aXN0IC4uXGF1 dG9nZW5cY29uZmlnLmluIHNlZCAtZiAuLi9tc2Rvcy9zZWQyeC5pbnAgPCAuLlxhdXRvZ2Vu XGNvbmZpZy5pbiA+IGNvbmZpZy50bXANCiA6c3JjNA0KIHNlZCAtZiAuLi9tc2Rvcy9zZWQy djIuaW5wIDxjb25maWcudG1wID5jb25maWcuaDINCi1SZW0gU2VlIGlmIERFQ0xfQUxJR04g Y2FuIGJlIHN1cHBvcnRlZCB3aXRoIHRoaXMgR0NDDQotcm0gLWYganVuay5jIGp1bmsubyBq dW5rIGp1bmsuZXhlDQotZWNobyBzdHJ1Y3QgeyBpbnQgaTsgY2hhciAqcDsgfSBfX2F0dHJp YnV0ZV9fKChfX2FsaWduZWRfXyg4KSkpIGZvbzsgID5qdW5rLmMNCi1yZW0gVHdvIHBlcmNl bnQgc2lnbnMgYmVjYXVzZSBpdCBpcyBhIHNwZWNpYWwgY2hhcmFjdGVyIGZvciBDT01NQU5E LkNPTS9DTUQNCi1yZW0gRmlsdGVyIHRocnUgU2VkIGJlY2F1c2UgIiYiIGlzIHNwZWNpYWwg Zm9yIENNRC5FWEUNCi1lY2hvIGludCBtYWluKHZvaWQpIHsgcmV0dXJuICh1bnNpZ25lZCBs b25nKSImImZvbyAlJSA4OyB9IHwgc2VkICJzLy4mLi9cJi8iICAgICAgICAgPj5qdW5rLmMN Ci1nY2MgLW8ganVuayBqdW5rLmMNCi1pZiBub3QgZXhpc3QganVuay5leGUgY29mZjJleGUg anVuaw0KLWp1bmsNCi1JZiBOb3QgRXJyb3JMZXZlbCAxIEdvdG8gYWxpZ25Paw0KLUVjaG8g V0FSTklORzogWW91ciBHQ0MgZG9lcyBub3Qgc3VwcG9ydCA4LWJ5dGUgYWxpZ25lZCB2YXJp YWJsZXMuDQotRWNobyBXQVJOSU5HOiBUaGVyZWZvcmUgRW1hY3MgY2Fubm90IHN1cHBvcnQg YnVmZmVycyBsYXJnZXIgdGhhbiAxMjhNQi4NCi1yZW0gVGhlIGZvbGxvd2luZyBsaW5lIGRp c2FibGVzIERFQ0xfQUxJR04gd2hpY2ggaW4gdHVybiBkaXNhYmxlcyBVU0VfTFNCX1RBRw0K LXJlbSBGb3IgZGV0YWlscyBzZWUgbGlzcC5oIHdoZXJlIGl0IGRlZmluZXMgVVNFX0xTQl9U QUcNCi1lY2hvICNkZWZpbmUgTk9fREVDTF9BTElHTiA+PmNvbmZpZy5oMg0KLTphbGlnbk9r DQogUmVtIFNlZSBpZiB0aGV5IGhhdmUgbGlieG1sMiBsYXRlciB0aGFuIHYyLjIuMCBpbnN0 YWxsZWQNCiBFY2hvIENoZWNraW5nIHdoZXRoZXIgbGlieG1sMiB2Mi4yLjEgb3IgbGF0ZXIg aXMgaW5zdGFsbGVkIC4uLg0KIHJtIC1mIGp1bmsuYyBqdW5rLm8ganVuayBqdW5rLmV4ZQ0K QEAgLTI4Myw2ICsyNjcsNyBAQAogSWYgRXhpc3QgYnVpbGQtYXV4XHNuaXBwZXRcYysrZGVm cy5oIHVwZGF0ZSBidWlsZC1hdXgvc25pcHBldC9jKytkZWZzLmggYnVpbGQtYXV4L3NuaXBw ZXQvY3h4ZGVmcy5oDQogSWYgRXhpc3QgYWxsb2NhLmluLmggdXBkYXRlIGFsbG9jYS5pbi5o IGFsbG9jYS5pbi1oDQogSWYgRXhpc3QgZ2V0b3B0LmluLmggdXBkYXRlIGdldG9wdC5pbi5o IGdldG9wdC5pbi1oDQorSWYgRXhpc3Qgc3RkYWxpZ24uaW4uaCB1cGRhdGUgc3RkYWxpZ24u aW4uaCBzdGRhbGlnbi5pbi1oDQogSWYgRXhpc3Qgc3RkYm9vbC5pbi5oIHVwZGF0ZSBzdGRi b29sLmluLmggc3RkYm9vbC5pbi1oDQogSWYgRXhpc3Qgc2lnbmFsLmluLmggdXBkYXRlIHNp Z25hbC5pbi5oIHNpZ25hbC5pbi1oDQogSWYgRXhpc3Qgc3RkZGVmLmluLmggdXBkYXRlIHN0 ZGRlZi5pbi5oICBzdGRkZWYuaW4taA0KQEAgLTM0Niw0ICszMzEsMyBAQAogc2V0IGRqZ3Bw X3Zlcj0NCiBzZXQgc3lzX21hbGxvYz0NCiBzZXQgbGlieG1sPQ0KLQ0KCj09PSBtb2RpZmll ZCBmaWxlICdjb25maWd1cmUuaW4nCi0tLSBjb25maWd1cmUuaW4JMjAxMS0xMS0wNCAyMjox Njo0NiArMDAwMAorKysgY29uZmlndXJlLmluCTIwMTEtMTEtMDcgMDU6NTk6MjkgKzAwMDAK QEAgLTEzNTEsMTkgKzEzNTEsNiBAQAogZG5sIENoZWNrIGZvciBlbmRpYW5lc3MKIEFDX0Nf QklHRU5ESUFOCiAKLUFDX0NBQ0hFX0NIRUNLKFtmb3IgIF9fYXR0cmlidXRlX18gKChfX2Fs aWduZWRfXyAoZXhwcikpKV0sCi0gIFtlbWFjc19jdl9hdHRyaWJ1dGVfYWxpZ25lZF0sCi0g IFtBQ19DT01QSUxFX0lGRUxTRSgKLSAgICAgW0FDX0xBTkdfUFJPR1JBTSgKLQlbW2NoYXIg X19hdHRyaWJ1dGVfXyAoKF9fYWxpZ25lZF9fICgxIDw8IDMpKSkgYztdXSwKLQlbW11dKV0s Ci0gICAgIFtlbWFjc19jdl9hdHRyaWJ1dGVfYWxpZ25lZD15ZXNdLAotICAgICBbZW1hY3Nf Y3ZfYXR0cmlidXRlX2FsaWduZWQ9bm9dKV0pCi1pZiB0ZXN0ICRlbWFjc19jdl9hdHRyaWJ1 dGVfYWxpZ25lZCA9IHllczsgdGhlbgotICBBQ19ERUZJTkUoW0hBVkVfQVRUUklCVVRFX0FM SUdORURdLCAxLAotICAgIFtEZWZpbmUgdG8gMSBpZiBHQ0Mtc3R5bGUgX19hdHRyaWJ1dGVf XyAoKF9fYWxpZ25lZF9fIChleHByKSkpIHdvcmtzLl0pCi1maQotCiBkbmwgY2hlY2sgZm9y IE1ha2UgZmVhdHVyZQogQUNfUFJPR19NQUtFX1NFVAogCgo9PT0gbW9kaWZpZWQgZmlsZSAn ZG9jL21pc2MvQ2hhbmdlTG9nJwotLS0gZG9jL21pc2MvQ2hhbmdlTG9nCTIwMTEtMTEtMDEg MTk6MjI6NTcgKzAwMDAKKysrIGRvYy9taXNjL0NoYW5nZUxvZwkyMDExLTExLTA4IDAxOjA3 OjE4ICswMDAwCkBAIC0xLDMgKzEsNyBAQAorMjAxMS0xMS0wOCAgUGF1bCBFZ2dlcnQgIDxl Z2dlcnRAY3MudWNsYS5lZHU+CisKKwkqIHRleGluZm8udGV4OiBNZXJnZSBmcm9tIGdudWxp Yi4KKwogMjAxMS0xMC0zMSAgS2F0c3VtaSBZYW1hb2thICA8eWFtYW9rYUBqcGwub3JnPgog CiAJKiBnbnVzLnRleGkgKE90aGVyIEdudXMgVmVyc2lvbnMpOiBSZW1vdmUuCgo9PT0gbW9k aWZpZWQgZmlsZSAnZG9jL21pc2MvdGV4aW5mby50ZXgnCi0tLSBkb2MvbWlzYy90ZXhpbmZv LnRleAkyMDExLTA5LTI2IDIxOjMwOjE4ICswMDAwCisrKyBkb2MvbWlzYy90ZXhpbmZvLnRl eAkyMDExLTExLTA3IDA1OjU2OjA0ICswMDAwCkBAIC0zLDcgKzMsNyBAQAogJSBMb2FkIHBs YWluIGlmIG5lY2Vzc2FyeSwgaS5lLiwgaWYgcnVubmluZyB1bmRlciBpbml0ZXguCiBcZXhw YW5kYWZ0ZXJcaWZ4XGNzbmFtZSBmbXRuYW1lXGVuZGNzbmFtZVxyZWxheFxpbnB1dCBwbGFp blxmaQogJQotXGRlZlx0ZXhpbmZvdmVyc2lvbnsyMDExLTA5LTIzLjA5fQorXGRlZlx0ZXhp bmZvdmVyc2lvbnsyMDExLTExLTA2LjA5fQogJQogJSBDb3B5cmlnaHQgMTk4NSwgMTk4Niwg MTk4OCwgMTk5MCwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwKICUgMTk5NiwgMTk5 NywgMTk5OCwgMTk5OSwgMjAwMCwgMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAw NiwKQEAgLTExNiw2ICsxMTYsNyBAQAogJSBTZXQgdXAgZml4ZWQgd29yZHMgZm9yIEVuZ2xp c2ggaWYgbm90IGFscmVhZHkgc2V0LgogXGlmeFxwdXR3b3JkQXBwZW5kaXhcdW5kZWZpbmVk ICBcZ2RlZlxwdXR3b3JkQXBwZW5kaXh7QXBwZW5kaXh9XGZpCiBcaWZ4XHB1dHdvcmRDaGFw dGVyXHVuZGVmaW5lZCAgIFxnZGVmXHB1dHdvcmRDaGFwdGVye0NoYXB0ZXJ9XGZpCitcaWZ4 XHB1dHdvcmRlcnJvclx1bmRlZmluZWQgICAgIFxnZGVmXHB1dHdvcmRmaWxle2Vycm9yfVxm aQogXGlmeFxwdXR3b3JkZmlsZVx1bmRlZmluZWQgICAgICBcZ2RlZlxwdXR3b3JkZmlsZXtm aWxlfVxmaQogXGlmeFxwdXR3b3JkaW5cdW5kZWZpbmVkICAgICAgICBcZ2RlZlxwdXR3b3Jk aW57aW59XGZpCiBcaWZ4XHB1dHdvcmRJbmRleElzRW1wdHlcdW5kZWZpbmVkICAgICAgIFxn ZGVmXHB1dHdvcmRJbmRleElzRW1wdHl7KEluZGV4IGlzIGVtcHR5KX1cZmkKQEAgLTExOTQs MjkgKzExOTUsMzEgQEAKICAgICBcZGVmXGltYWdld2lkdGh7IzJ9XHNldGJveDAgPSBcaGJv eHtcaWdub3Jlc3BhY2VzICMyfSUKICAgICBcZGVmXGltYWdlaGVpZ2h0eyMzfVxzZXRib3gy ID0gXGhib3h7XGlnbm9yZXNwYWNlcyAjM30lCiAgICAgJQotICAgICUgcGRmdGV4IChhbmQg dGhlIFBERiBmb3JtYXQpIHN1cHBvcnQgLnBuZywgLmpwZywgLnBkZiAoYW1vbmcKLSAgICAl IG90aGVycykuICBMZXQncyB0cnkgaW4gdGhhdCBvcmRlci4KKyAgICAlIHBkZnRleCAoYW5k IHRoZSBQREYgZm9ybWF0KSBzdXBwb3J0IC5wZGYsIC5wbmcsIC5qcGcgKGFtb25nCisgICAg JSBvdGhlcnMpLiAgTGV0J3MgdHJ5IGluIHRoYXQgb3JkZXIsIFBERiBmaXJzdCBzaW5jZSBp ZgorICAgICUgc29tZW9uZSBoYXMgYSBzY2FsYWJsZSBpbWFnZSwgcHJlc3VtYWJseSBiZXR0 ZXIgdG8gdXNlIHRoYXQgdGhhbiBhCisgICAgJSBiaXRtYXAuCiAgICAgXGxldFxwZGZpbWdl eHQ9XGVtcHR5CiAgICAgXGJlZ2luZ3JvdXAKLSAgICAgIFxvcGVuaW4gMSAjMS5wbmcgXGlm ZW9mIDEKLSAgICAgICAgXG9wZW5pbiAxICMxLmpwZyBcaWZlb2YgMQotICAgICAgICAgIFxv cGVuaW4gMSAjMS5qcGVnIFxpZmVvZiAxCi0gICAgICAgICAgICBcb3BlbmluIDEgIzEuSlBH IFxpZmVvZiAxCi0gICAgICAgICAgICAgIFxvcGVuaW4gMSAjMS5wZGYgXGlmZW9mIDEKLSAg ICAgICAgICAgICAgICBcb3BlbmluIDEgIzEuUERGIFxpZmVvZiAxCisgICAgICBcb3Blbmlu IDEgIzEucGRmIFxpZmVvZiAxCisgICAgICAgIFxvcGVuaW4gMSAjMS5QREYgXGlmZW9mIDEK KyAgICAgICAgICBcb3BlbmluIDEgIzEucG5nIFxpZmVvZiAxCisgICAgICAgICAgICBcb3Bl bmluIDEgIzEuanBnIFxpZmVvZiAxCisgICAgICAgICAgICAgIFxvcGVuaW4gMSAjMS5qcGVn IFxpZmVvZiAxCisgICAgICAgICAgICAgICAgXG9wZW5pbiAxICMxLkpQRyBcaWZlb2YgMQog ICAgICAgICAgICAgICAgICAgXGVycmhlbHAgPSBcbm9wZGZpbWFnZWhlbHAKICAgICAgICAg ICAgICAgICAgIFxlcnJtZXNzYWdle0NvdWxkIG5vdCBmaW5kIGltYWdlIGZpbGUgIzEgZm9y IHBkZn0lCi0gICAgICAgICAgICAgICAgXGVsc2UgXGdkZWZccGRmaW1nZXh0e1BERn0lCisg ICAgICAgICAgICAgICAgXGVsc2UgXGdkZWZccGRmaW1nZXh0e0pQR30lCiAgICAgICAgICAg ICAgICAgXGZpCi0gICAgICAgICAgICAgIFxlbHNlIFxnZGVmXHBkZmltZ2V4dHtwZGZ9JQor ICAgICAgICAgICAgICBcZWxzZSBcZ2RlZlxwZGZpbWdleHR7anBlZ30lCiAgICAgICAgICAg ICAgIFxmaQotICAgICAgICAgICAgXGVsc2UgXGdkZWZccGRmaW1nZXh0e0pQR30lCisgICAg ICAgICAgICBcZWxzZSBcZ2RlZlxwZGZpbWdleHR7anBnfSUKICAgICAgICAgICAgIFxmaQot ICAgICAgICAgIFxlbHNlIFxnZGVmXHBkZmltZ2V4dHtqcGVnfSUKKyAgICAgICAgICBcZWxz ZSBcZ2RlZlxwZGZpbWdleHR7cG5nfSUKICAgICAgICAgICBcZmkKLSAgICAgICAgXGVsc2Ug XGdkZWZccGRmaW1nZXh0e2pwZ30lCisgICAgICAgIFxlbHNlIFxnZGVmXHBkZmltZ2V4dHtQ REZ9JQogICAgICAgICBcZmkKLSAgICAgIFxlbHNlIFxnZGVmXHBkZmltZ2V4dHtwbmd9JQor ICAgICAgXGVsc2UgXGdkZWZccGRmaW1nZXh0e3BkZn0lCiAgICAgICBcZmkKICAgICAgIFxj bG9zZWluIDEKICAgICBcZW5kZ3JvdXAKQEAgLTIzNzIsNyArMjM3NSw5IEBACiAgIFxlbHNl XGlmeFxuZXh0LSUKICAgXGVsc2VcaWZ4XG5leHQuJQogICBcZWxzZVxwdGV4c2xhc2gKLSAg XGZpXGZpXGZpfQorICBcZmlcZmlcZmkKKyAgXGFmdGVyc21hcnRpYworfQogCiAlIGxpa2Ug XHNtYXJ0c2xhbnRlZCBleGNlcHQgdW5jb25kaXRpb25hbGx5IHVzZXMgXHR0c2wsIGFuZCBu byBpYy4KICUgQHZhciBpcyBzZXQgdG8gdGhpcyBmb3IgZGVmdW4gYXJndW1lbnRzLgpAQCAt MjM4Miw5ICsyMzg3LDE1IEBACiAlIHR0c2wgZm9yIGJvb2sgdGl0bGVzLCBkbyB3ZT8KIFxk ZWZcY2l0ZSMxe3tcc2wgIzF9XGZ1dHVyZWxldFxuZXh0XHNtYXJ0aXRhbGljY29ycmVjdGlv bn0KIAorXGRlZlxhZnRlcnNtYXJ0aWN7fQorXGRlZlx2YXIjMXslCisgIFxsZXRcc2F2ZWFm dGVyc21hcnRpYyA9IFxhZnRlcnNtYXJ0aWMKKyAgXGRlZlxhZnRlcnNtYXJ0aWN7XG51bGxc bGV0XGFmdGVyc21hcnRpYz1cc2F2ZWFmdGVyc21hcnRpY30lCisgIFxzbWFydHNsYW50ZWR7 IzF9JQorfQorCiBcbGV0XGk9XHNtYXJ0aXRhbGljCiBcbGV0XHNsYW50ZWQ9XHNtYXJ0c2xh bnRlZAotXGRlZlx2YXIjMXtcc21hcnRzbGFudGVkeyMxfX0KIFxsZXRcZGZuPVxzbWFydHNs YW50ZWQKIFxsZXRcZW1waD1cc21hcnRpdGFsaWMKIApAQCAtMjQ4MCw3ICsyNDkxLDcgQEAK ICAgICBccGxhaW5mcmVuY2hzcGFjaW5nCiAgICAgIzElCiAgIH0lCi0gIFxudWxsCisgIFxu dWxsICUgcmVzZXQgc3BhY2VmYWN0b3IgdG8gMTAwMAogfQogCiAlIFdlICptdXN0KiB0dXJu IG9uIGh5cGhlbmF0aW9uIGF0IGAtJyBhbmQgYF8nIGluIEBjb2RlLgpAQCAtMjc2Miw2ICsy NzczLDcgQEAKICAgXGlmeFx0ZW1wXGVtcHR5IFxlbHNlCiAgICAgXHNwYWNlICh7XHVuc2Vw c3BhY2VzIFxpZ25vcmVzcGFjZXMgXHRlbXAgXHVuc2tpcH0pJQogICBcZmkKKyAgXG51bGwg JSByZXNldCBcc3BhY2VmYWN0b3I9MTAwMAogfQogCiAlIEBhYmJyIGZvciAiQ29tcHV0LiBK LiIgYW5kIHRoZSBsaWtlLgpAQCAtMjc3NCw2ICsyNzg2LDcgQEAKICAgXGlmeFx0ZW1wXGVt cHR5IFxlbHNlCiAgICAgXHNwYWNlICh7XHVuc2Vwc3BhY2VzIFxpZ25vcmVzcGFjZXMgXHRl bXAgXHVuc2tpcH0pJQogICBcZmkKKyAgXG51bGwgJSByZXNldCBcc3BhY2VmYWN0b3I9MTAw MAogfQogCiAlIEBhc2lzIGp1c3QgeWllbGRzIGl0cyBhcmd1bWVudC4gIFVzZWQgd2l0aCBA dGFibGUsIGZvciBleGFtcGxlLgpAQCAtMjk3OSw3ICsyOTkyLDcgQEAKIHtcdGVudHQgXGds b2JhbFxkaW1lbjAgPSAzZW19JSBXaWR0aCBvZiB0aGUgYm94LgogXGRpbWVuMiA9IC41NXB0 ICUgVGhpY2tuZXNzIG9mIHJ1bGVzCiAlIFRoZSB0ZXh0LiAoYHInIGlzIG9wZW4gb24gdGhl IHJpZ2h0LCBgZScgc29tZXdoYXQgbGVzcyBzbyBvbiB0aGUgbGVmdC4pCi1cc2V0Ym94MCA9 IFxoYm94e1xrZXJuLS43NXB0IFxyZWR1Y2Vkc2YgZXJyb3Jca2Vybi0xLjVwdH0KK1xzZXRi b3gwID0gXGhib3h7XGtlcm4tLjc1cHQgXHJlZHVjZWRzZiBccHV0d29yZGVycm9yXGtlcm4t MS41cHR9CiAlCiBcc2V0Ym94XGVycm9yYm94PVxoYm94IHRvIFxkaW1lbjB7XGhmaWwKICAg IFxoc2l6ZSA9IFxkaW1lbjAgXGFkdmFuY2VcaHNpemUgYnkgLTUuOHB0ICUgU3BhY2UgdG8g bGVmdCtyaWdodC4KQEAgLTgxMDMsNyArODExNiw3IEBACiAlIHNwYWNlIHRvIHByZXZlbnQg c3RyYW5nZSBleHBhbnNpb24gZXJyb3JzLikKIFxkZWZcc3VwZXJlamVjdHtccGFyXHBlbmFs dHkgLTIwMDAwXGZvb3Rub3Rlbm8gPTAgfQogCi0lIEBmb290bm90ZXN0eWxlIGlzIG1lYW5p bmdmdWwgZm9yIGluZm8gb3V0cHV0IG9ubHkuCislIEBmb290bm90ZXN0eWxlIGlzIG1lYW5p bmdmdWwgZm9yIEluZm8gb3V0cHV0IG9ubHkuCiBcbGV0XGZvb3Rub3Rlc3R5bGU9XGNvbW1l bnQKIAoge1xjYXRjb2RlIGBcQD0xMQpAQCAtODE2Niw2ICs4MTc5LDggQEAKICAgJSBleHBh bmRzIGludG8gYSBib3gsIGl0IG11c3QgY29tZSB3aXRoaW4gdGhlIHBhcmFncmFwaCwgbGVz dCBpdAogICAlIHByb3ZpZGUgYSBwbGFjZSB3aGVyZSBUZVggY2FuIHNwbGl0IHRoZSBmb290 bm90ZS4KICAgXGZvb3RzdHJ1dAorICAlCisgICUgSW52b2tlIHJlc3Qgb2YgcGxhaW4gVGVY IGZvb3Rub3RlIHJvdXRpbmUuCiAgIFxmdXR1cmVsZXRcbmV4dFxmb0B0CiB9CiB9JWVuZCBc Y2F0Y29kZSBgXEA9MTEKCj09PSBtb2RpZmllZCBmaWxlICdsaWIvZ2V0dGV4dC5oJwotLS0g bGliL2dldHRleHQuaAkyMDExLTAyLTE1IDA0OjUzOjI5ICswMDAwCisrKyBsaWIvZ2V0dGV4 dC5oCTIwMTEtMTAtMjcgMTk6NTE6MjYgKzAwMDAKQEAgLTE4NSw3ICsxODUsNyBAQAogI2lu Y2x1ZGUgPHN0cmluZy5oPgogCiAjZGVmaW5lIF9MSUJHRVRURVhUX0hBVkVfVkFSSUFCTEVf U0laRV9BUlJBWVMgXAotICAoKChfX0dOVUNfXyA+PSAzIHx8IF9fR05VR19fID49IDIpICYm ICFfX1NUUklDVF9BTlNJX18pIFwKKyAgKCgoX19HTlVDX18gPj0gMyB8fCBfX0dOVUdfXyA+ PSAyKSAmJiAhZGVmaW5lZCBfX1NUUklDVF9BTlNJX18pIFwKICAgIC8qIHx8IF9fU1REQ19W RVJTSU9OX18gPj0gMTk5OTAxTCAqLyApCiAKICNpZiAhX0xJQkdFVFRFWFRfSEFWRV9WQVJJ QUJMRV9TSVpFX0FSUkFZUwoKPT09IG1vZGlmaWVkIGZpbGUgJ2xpYi9nbnVsaWIubWsnCi0t LSBsaWIvZ251bGliLm1rCTIwMTEtMDktMjYgMjE6MzA6MTggKzAwMDAKKysrIGxpYi9nbnVs aWIubWsJMjAxMS0xMC0yNyAxOTo1MToyNiArMDAwMApAQCAtMjEsNyArMjEsNyBAQAogIyB0 aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgYXMgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFt LgogIwogIyBHZW5lcmF0ZWQgYnkgZ251bGliLXRvb2wuCi0jIFJlcHJvZHVjZSBieTogZ251 bGliLXRvb2wgLS1pbXBvcnQgLS1kaXI9LiAtLWxpYj1saWJnbnUgLS1zb3VyY2UtYmFzZT1s aWIgLS1tNC1iYXNlPW00IC0tZG9jLWJhc2U9ZG9jIC0tdGVzdHMtYmFzZT10ZXN0cyAtLWF1 eC1kaXI9YnVpbGQtYXV4IC0tYXZvaWQ9bXN2Yy1pbnZhbCAtLWF2b2lkPW1zdmMtbm90aHJv dyAtLWF2b2lkPXBhdGhtYXggLS1hdm9pZD1yYWlzZSAtLWF2b2lkPXRocmVhZGxpYiAtLW1h a2VmaWxlLW5hbWU9Z251bGliLm1rIC0tY29uZGl0aW9uYWwtZGVwZW5kZW5jaWVzIC0tbm8t bGlidG9vbCAtLW1hY3JvLXByZWZpeD1nbCAtLW5vLXZjLWZpbGVzIGFsbG9jYS1vcHQgY2Fy ZWFkbGlua2F0IGNyeXB0by9tZDUgY3J5cHRvL3NoYTEgY3J5cHRvL3NoYTI1NiBjcnlwdG8v c2hhNTEyIGR0b2FzdHIgZHVwMiBmaWxlbW9kZSBnZXRsb2FkYXZnIGdldG9wdC1nbnUgaWdu b3JlLXZhbHVlIGludHByb3BzIGxzdGF0IG1rdGltZSBwdGhyZWFkX3NpZ21hc2sgcmVhZGxp bmsgc29ja2xlbiBzdGRhcmcgc3RkaW8gc3RyZnRpbWUgc3RydG9pbWF4IHN0cnRvdW1heCBz eW1saW5rIHN5c19zdGF0CisjIFJlcHJvZHVjZSBieTogZ251bGliLXRvb2wgLS1pbXBvcnQg LS1kaXI9LiAtLWxpYj1saWJnbnUgLS1zb3VyY2UtYmFzZT1saWIgLS1tNC1iYXNlPW00IC0t ZG9jLWJhc2U9ZG9jIC0tdGVzdHMtYmFzZT10ZXN0cyAtLWF1eC1kaXI9YnVpbGQtYXV4IC0t YXZvaWQ9bXN2Yy1pbnZhbCAtLWF2b2lkPW1zdmMtbm90aHJvdyAtLWF2b2lkPXBhdGhtYXgg LS1hdm9pZD1yYWlzZSAtLWF2b2lkPXRocmVhZGxpYiAtLW1ha2VmaWxlLW5hbWU9Z251bGli Lm1rIC0tY29uZGl0aW9uYWwtZGVwZW5kZW5jaWVzIC0tbm8tbGlidG9vbCAtLW1hY3JvLXBy ZWZpeD1nbCAtLW5vLXZjLWZpbGVzIGFsbG9jYS1vcHQgY2FyZWFkbGlua2F0IGNyeXB0by9t ZDUgY3J5cHRvL3NoYTEgY3J5cHRvL3NoYTI1NiBjcnlwdG8vc2hhNTEyIGR0b2FzdHIgZHVw MiBmaWxlbW9kZSBnZXRsb2FkYXZnIGdldG9wdC1nbnUgaWdub3JlLXZhbHVlIGludHByb3Bz IGxzdGF0IG1rdGltZSBwdGhyZWFkX3NpZ21hc2sgcmVhZGxpbmsgc29ja2xlbiBzdGRhbGln biBzdGRhcmcgc3RkaW8gc3RyZnRpbWUgc3RydG9pbWF4IHN0cnRvdW1heCBzeW1saW5rIHN5 c19zdGF0CiAKIAogTU9TVExZQ0xFQU5GSUxFUyArPSBjb3JlICouc3RhY2tkdW1wCkBAIC00 MjEsNiArNDIxLDI5IEBACiAKICMjIGVuZCAgIGdudWxpYiBtb2R1bGUgc3RhdAogCisjIyBi ZWdpbiBnbnVsaWIgbW9kdWxlIHN0ZGFsaWduCisKK0JVSUxUX1NPVVJDRVMgKz0gJChTVERB TElHTl9IKQorCisjIFdlIG5lZWQgdGhlIGZvbGxvd2luZyBpbiBvcmRlciB0byBjcmVhdGUg PHN0ZGFsaWduLmg+IHdoZW4gdGhlIHN5c3RlbQorIyBkb2Vzbid0IGhhdmUgb25lIHRoYXQg d29ya3MuCitpZiBHTF9HRU5FUkFURV9TVERBTElHTl9ICitzdGRhbGlnbi5oOiBzdGRhbGln bi5pbi5oICQodG9wX2J1aWxkZGlyKS9jb25maWcuc3RhdHVzCisJJChBTV9WX0dFTilybSAt ZiAkQC10ICRAICYmIFwKKwl7IGVjaG8gJy8qIERPIE5PVCBFRElUISBHRU5FUkFURUQgQVVU T01BVElDQUxMWSEgKi8nOyBcCisJICBjYXQgJChzcmNkaXIpL3N0ZGFsaWduLmluLmg7IFwK Kwl9ID4gJEAtdCAmJiBcCisJbXYgJEAtdCAkQAorZWxzZQorc3RkYWxpZ24uaDogJCh0b3Bf YnVpbGRkaXIpL2NvbmZpZy5zdGF0dXMKKwlybSAtZiAkQAorZW5kaWYKK01PU1RMWUNMRUFO RklMRVMgKz0gc3RkYWxpZ24uaCBzdGRhbGlnbi5oLXQKKworRVhUUkFfRElTVCArPSBzdGRh bGlnbi5pbi5oCisKKyMjIGVuZCAgIGdudWxpYiBtb2R1bGUgc3RkYWxpZ24KKwogIyMgYmVn aW4gZ251bGliIG1vZHVsZSBzdGRhcmcKIAogQlVJTFRfU09VUkNFUyArPSAkKFNUREFSR19I KQpAQCAtNzEwLDYgKzczMyw3IEBACiAJICAgICAgLWUgJ3MvQCcnR05VTElCX01LT1NURU1Q UycnQC8kKEdOVUxJQl9NS09TVEVNUFMpL2cnIFwKIAkgICAgICAtZSAncy9AJydHTlVMSUJf TUtTVEVNUCcnQC8kKEdOVUxJQl9NS1NURU1QKS9nJyBcCiAJICAgICAgLWUgJ3MvQCcnR05V TElCX01LU1RFTVBTJydALyQoR05VTElCX01LU1RFTVBTKS9nJyBcCisJICAgICAgLWUgJ3Mv QCcnR05VTElCX1BPU0lYX09QRU5QVCcnQC8kKEdOVUxJQl9QT1NJWF9PUEVOUFQpL2cnIFwK IAkgICAgICAtZSAncy9AJydHTlVMSUJfUFRTTkFNRScnQC8kKEdOVUxJQl9QVFNOQU1FKS9n JyBcCiAJICAgICAgLWUgJ3MvQCcnR05VTElCX1BVVEVOVicnQC8kKEdOVUxJQl9QVVRFTlYp L2cnIFwKIAkgICAgICAtZSAncy9AJydHTlVMSUJfUkFORE9NX1InJ0AvJChHTlVMSUJfUkFO RE9NX1IpL2cnIFwKQEAgLTczNiw2ICs3NjAsNyBAQAogCSAgICAgIC1lICdzfEAnJ0hBVkVf TUtPU1RFTVBTJydAfCQoSEFWRV9NS09TVEVNUFMpfGcnIFwKIAkgICAgICAtZSAnc3xAJydI QVZFX01LU1RFTVAnJ0B8JChIQVZFX01LU1RFTVApfGcnIFwKIAkgICAgICAtZSAnc3xAJydI QVZFX01LU1RFTVBTJydAfCQoSEFWRV9NS1NURU1QUyl8ZycgXAorCSAgICAgIC1lICdzfEAn J0hBVkVfUE9TSVhfT1BFTlBUJydAfCQoSEFWRV9QT1NJWF9PUEVOUFQpfGcnIFwKIAkgICAg ICAtZSAnc3xAJydIQVZFX1BUU05BTUUnJ0B8JChIQVZFX1BUU05BTUUpfGcnIFwKIAkgICAg ICAtZSAnc3xAJydIQVZFX1JBTkRPTV9IJydAfCQoSEFWRV9SQU5ET01fSCl8ZycgXAogCSAg ICAgIC1lICdzfEAnJ0hBVkVfUkFORE9NX1InJ0B8JChIQVZFX1JBTkRPTV9SKXxnJyBcCgo9 PT0gbW9kaWZpZWQgZmlsZSAnbGliL21kNS5jJwotLS0gbGliL21kNS5jCTIwMTEtMDItMTkg MDc6Mjg6MjkgKzAwMDAKKysrIGxpYi9tZDUuYwkyMDExLTEwLTE3IDAxOjIyOjE5ICswMDAw CkBAIC0yNCw3ICsyNCw4IEBACiAKICNpbmNsdWRlICJtZDUuaCIKIAotI2luY2x1ZGUgPHN0 ZGRlZi5oPgorI2luY2x1ZGUgPHN0ZGFsaWduLmg+CisjaW5jbHVkZSA8c3RkaW50Lmg+CiAj aW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lz L3R5cGVzLmg+CkBAIC0yNTQsOCArMjU1LDcgQEAKICAgaWYgKGxlbiA+PSA2NCkKICAgICB7 CiAjaWYgIV9TVFJJTkdfQVJDSF91bmFsaWduZWQKLSMgZGVmaW5lIGFsaWdub2YodHlwZSkg b2Zmc2V0b2YgKHN0cnVjdCB7IGNoYXIgYzsgdHlwZSB4OyB9LCB4KQotIyBkZWZpbmUgVU5B TElHTkVEX1AocCkgKCgoc2l6ZV90KSBwKSAlIGFsaWdub2YgKHVpbnQzMl90KSAhPSAwKQor IyBkZWZpbmUgVU5BTElHTkVEX1AocCkgKCh1aW50cHRyX3QpIChwKSAlIGFsaWdub2YgKHVp bnQzMl90KSAhPSAwKQogICAgICAgaWYgKFVOQUxJR05FRF9QIChidWZmZXIpKQogICAgICAg ICB3aGlsZSAobGVuID4gNjQpCiAgICAgICAgICAgewoKPT09IG1vZGlmaWVkIGZpbGUgJ2xp Yi9zaGExLmMnCi0tLSBsaWIvc2hhMS5jCTIwMTEtMDUtMjQgMDg6MTI6NTIgKzAwMDAKKysr IGxpYi9zaGExLmMJMjAxMS0xMC0xNyAwMToyMjoxOSArMDAwMApAQCAtMjYsNyArMjYsOCBA QAogCiAjaW5jbHVkZSAic2hhMS5oIgogCi0jaW5jbHVkZSA8c3RkZGVmLmg+CisjaW5jbHVk ZSA8c3RkYWxpZ24uaD4KKyNpbmNsdWRlIDxzdGRpbnQuaD4KICNpbmNsdWRlIDxzdGRsaWIu aD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KIApAQCAtMjQxLDggKzI0Miw3IEBACiAgIGlmIChs ZW4gPj0gNjQpCiAgICAgewogI2lmICFfU1RSSU5HX0FSQ0hfdW5hbGlnbmVkCi0jIGRlZmlu ZSBhbGlnbm9mKHR5cGUpIG9mZnNldG9mIChzdHJ1Y3QgeyBjaGFyIGM7IHR5cGUgeDsgfSwg eCkKLSMgZGVmaW5lIFVOQUxJR05FRF9QKHApICgoKHNpemVfdCkgcCkgJSBhbGlnbm9mICh1 aW50MzJfdCkgIT0gMCkKKyMgZGVmaW5lIFVOQUxJR05FRF9QKHApICgodWludHB0cl90KSAo cCkgJSBhbGlnbm9mICh1aW50MzJfdCkgIT0gMCkKICAgICAgIGlmIChVTkFMSUdORURfUCAo YnVmZmVyKSkKICAgICAgICAgd2hpbGUgKGxlbiA+IDY0KQogICAgICAgICAgIHsKCj09PSBt b2RpZmllZCBmaWxlICdsaWIvc2hhMjU2LmMnCi0tLSBsaWIvc2hhMjU2LmMJMjAxMS0wNi0y MSAwODo0NTozOSArMDAwMAorKysgbGliL3NoYTI1Ni5jCTIwMTEtMTAtMTcgMDE6MjI6MTkg KzAwMDAKQEAgLTI0LDcgKzI0LDggQEAKIAogI2luY2x1ZGUgInNoYTI1Ni5oIgogCi0jaW5j bHVkZSA8c3RkZGVmLmg+CisjaW5jbHVkZSA8c3RkYWxpZ24uaD4KKyNpbmNsdWRlIDxzdGRp bnQuaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KIApAQCAt MzczLDggKzM3NCw3IEBACiAgIGlmIChsZW4gPj0gNjQpCiAgICAgewogI2lmICFfU1RSSU5H X0FSQ0hfdW5hbGlnbmVkCi0jIGRlZmluZSBhbGlnbm9mKHR5cGUpIG9mZnNldG9mIChzdHJ1 Y3QgeyBjaGFyIGM7IHR5cGUgeDsgfSwgeCkKLSMgZGVmaW5lIFVOQUxJR05FRF9QKHApICgo KHNpemVfdCkgcCkgJSBhbGlnbm9mICh1aW50MzJfdCkgIT0gMCkKKyMgZGVmaW5lIFVOQUxJ R05FRF9QKHApICgodWludHB0cl90KSAocCkgJSBhbGlnbm9mICh1aW50MzJfdCkgIT0gMCkK ICAgICAgIGlmIChVTkFMSUdORURfUCAoYnVmZmVyKSkKICAgICAgICAgd2hpbGUgKGxlbiA+ IDY0KQogICAgICAgICAgIHsKCj09PSBtb2RpZmllZCBmaWxlICdsaWIvc2hhNTEyLmMnCi0t LSBsaWIvc2hhNTEyLmMJMjAxMS0wNi0yMSAwODo0NTozOSArMDAwMAorKysgbGliL3NoYTUx Mi5jCTIwMTEtMTAtMTcgMDE6MjI6MTkgKzAwMDAKQEAgLTI0LDcgKzI0LDggQEAKIAogI2lu Y2x1ZGUgInNoYTUxMi5oIgogCi0jaW5jbHVkZSA8c3RkZGVmLmg+CisjaW5jbHVkZSA8c3Rk YWxpZ24uaD4KKyNpbmNsdWRlIDxzdGRpbnQuaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNp bmNsdWRlIDxzdHJpbmcuaD4KIApAQCAtMzgxLDggKzM4Miw3IEBACiAgIGlmIChsZW4gPj0g MTI4KQogICAgIHsKICNpZiAhX1NUUklOR19BUkNIX3VuYWxpZ25lZAotIyBkZWZpbmUgYWxp Z25vZih0eXBlKSBvZmZzZXRvZiAoc3RydWN0IHsgY2hhciBjOyB0eXBlIHg7IH0sIHgpCi0j IGRlZmluZSBVTkFMSUdORURfUChwKSAoKChzaXplX3QpIHApICUgYWxpZ25vZiAodTY0KSAh PSAwKQorIyBkZWZpbmUgVU5BTElHTkVEX1AocCkgKCh1aW50cHRyX3QpIChwKSAlIGFsaWdu b2YgKHU2NCkgIT0gMCkKICAgICAgIGlmIChVTkFMSUdORURfUCAoYnVmZmVyKSkKICAgICAg ICAgd2hpbGUgKGxlbiA+IDEyOCkKICAgICAgICAgICB7Cgo9PT0gYWRkZWQgZmlsZSAnbGli L3N0ZGFsaWduLmluLmgnCi0tLSBsaWIvc3RkYWxpZ24uaW4uaAkxOTcwLTAxLTAxIDAwOjAw OjAwICswMDAwCisrKyBsaWIvc3RkYWxpZ24uaW4uaAkyMDExLTExLTA3IDA1OjU2OjA0ICsw MDAwCkBAIC0wLDAgKzEsODkgQEAKKy8qIEEgc3Vic3RpdHV0ZSBmb3IgSVNPIEMgMXggPHN0 ZGFsaWduLmg+LgorCisgICBDb3B5cmlnaHQgMjAxMSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp b24sIEluYy4KKworICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAgIGl0IHVuZGVyIHRoZSB0ZXJtcyBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgICB0 aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAzLCBvciAoYXQg eW91ciBvcHRpb24pCisgICBhbnkgbGF0ZXIgdmVyc2lvbi4KKworICAgVGhpcyBwcm9ncmFt IGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisg ICBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3 YXJyYW50eSBvZgorICAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICAgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug Zm9yIG1vcmUgZGV0YWlscy4KKworICAgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29w eSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAgIGFsb25nIHdpdGggdGhp cyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp b24sCisgICBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQsIEZpZnRoIEZsb29yLCBCb3N0b24s IE1BIDAyMTEwLTEzMDEsIFVTQS4gICovCisKKy8qIFdyaXR0ZW4gYnkgUGF1bCBFZ2dlcnQg YW5kIEJydW5vIEhhaWJsZS4gICovCisKKyNpZm5kZWYgX0dMX1NUREFMSUdOX0gKKyNkZWZp bmUgX0dMX1NUREFMSUdOX0gKKworLyogSVNPIEMxWCA8c3RkYWxpZ24uaD4gZm9yIHBsYXRm b3JtcyB0aGF0IGxhY2sgaXQuCisKKyAgIFJlZmVyZW5jZXM6CisgICBJU08gQzFYIDxodHRw Oi8vd3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cxNC93d3cvZG9jcy9uMTU3MC5wZGY+ CisgICBzZWN0aW9ucyA2LjUuMy40LCA2LjcuNSwgNy4xNS4KKyAgIEMrKzBYIDxodHRwOi8v d3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDExL24zMjQy LnBkZj4KKyAgIHNlY3Rpb24gMTguMTAuICovCisKKy8qIGFsaWdub2YgKFRZUEUpLCBhbHNv IGtub3duIGFzIF9BbGlnbm9mIChUWVBFKSwgeWllbGRzIHRoZSBhbGlnbm1lbnQKKyAgIHJl cXVpcmVtZW50IG9mIGEgc3RydWN0dXJlIG1lbWJlciAoaS5lLiwgc2xvdCBvciBmaWVsZCkg dGhhdCBpcyBvZgorICAgdHlwZSBUWVBFLCBhcyBhbiBpbnRlZ2VyIGNvbnN0YW50IGV4cHJl c3Npb24uCisKKyAgIFRoaXMgZGlmZmVycyBmcm9tIEdDQydzIF9fYWxpZ25vZl9fIG9wZXJh dG9yLCB3aGljaCBjYW4geWllbGQgYQorICAgYmV0dGVyLXBlcmZvcm1pbmcgYWxpZ25tZW50 IGZvciBhbiBvYmplY3Qgb2YgdGhhdCB0eXBlLiAgRm9yCisgICBleGFtcGxlLCBvbiB4ODYg d2l0aCBHQ0MsIF9fYWxpZ25vZl9fIChkb3VibGUpIGFuZCBfX2FsaWdub2ZfXworICAgKGxv bmcgbG9uZykgYXJlIDgsIHdoZXJlYXMgYWxpZ25vZiAoZG91YmxlKSBhbmQgYWxpZ25vZiAo bG9uZyBsb25nKQorICAgYXJlIDQgdW5sZXNzIHRoZSBvcHRpb24gJy1tYWxpZ24tZG91Ymxl JyBpcyB1c2VkLgorCisgICBUaGUgcmVzdWx0IGNhbm5vdCBiZSB1c2VkIGFzIGEgdmFsdWUg Zm9yIGFuICdlbnVtJyBjb25zdGFudCwgaWYgeW91CisgICB3YW50IHRvIGJlIHBvcnRhYmxl IHRvIEhQLVVYIDEwLjIwIGNjIGFuZCBBSVggMy4yLjUgeGxjLiAgKi8KKyNpbmNsdWRlIDxz dGRkZWYuaD4KKyNpZiBkZWZpbmVkIF9fY3BsdXNwbHVzCisgICB0ZW1wbGF0ZSA8Y2xhc3Mg X190PiBzdHJ1Y3QgX19hbGlnbm9mX2hlbHBlciB7IGNoYXIgX19hOyBfX3QgX19iOyB9Owor IyBkZWZpbmUgX0FsaWdub2YodHlwZSkgb2Zmc2V0b2YgKF9fYWxpZ25vZl9oZWxwZXI8dHlw ZT4sIF9fYikKKyNlbHNlCisjIGRlZmluZSBfQWxpZ25vZih0eXBlKSBvZmZzZXRvZiAoc3Ry dWN0IHsgY2hhciBfX2E7IHR5cGUgX19iOyB9LCBfX2IpCisjZW5kaWYKKyNkZWZpbmUgYWxp Z25vZiBfQWxpZ25vZgorI2RlZmluZSBfX2FsaWdub2ZfaXNfZGVmaW5lZCAxCisKKy8qIGFs aWduYXMgKEEpLCBhbHNvIGtub3duIGFzIF9BbGlnbmFzIChBKSwgYWxpZ25zIGEgdmFyaWFi bGUgb3IgdHlwZQorICAgdG8gdGhlIGFsaWdubWVudCBBLCB3aGVyZSBBIGlzIGFuIGludGVn ZXIgY29uc3RhbnQgZXhwcmVzc2lvbi4gIEZvcgorICAgZXhhbXBsZToKKworICAgICAgaW50 IGFsaWduYXMgKDgpIGZvbzsKKyAgICAgIHN0cnVjdCBzIHsgaW50IGE7IGludCBhbGlnbmFz ICg4KSBiYXI7IH07CisKKyAgIGFsaWducyB0aGUgYWRkcmVzcyBvZiBGT08gYW5kIHRoZSBv ZmZzZXQgb2YgQkFSIHRvIGJlIG11bHRpcGxlcyBvZiA4LgorCisgICBBIHNob3VsZCBiZSBh IHBvd2VyIG9mIHR3byB0aGF0IGlzIGF0IGxlYXN0IHRoZSB0eXBlJ3MgYWxpZ25tZW50Cisg ICBhbmQgYXQgbW9zdCB0aGUgaW1wbGVtZW50YXRpb24ncyBhbGlnbm1lbnQgbGltaXQuICBU aGlzIGxpbWl0IGlzCisgICAyKioyOCBvbiB0eXBpY2FsIEdOVWlzaCBob3N0cywgYW5kIDIq KjEzIG9uIE1TVkMuICBUbyBiZSBwb3J0YWJsZQorICAgdG8gTVNWQyB0aHJvdWdoIGF0IGxl YXN0IHZlcnNpb24gMTAuMCwgQSBzaG91bGQgYmUgYW4gaW50ZWdlcgorICAgY29uc3RhbnQs IGFzIE1TVkMgZG9lcyBub3Qgc3VwcG9ydCBleHByZXNzaW9ucyBzdWNoIGFzIDEgPDwgMy4K KyAgIFRvIGJlIHBvcnRhYmxlIHRvIFN1biBDIDUuMTEsIGRvIG5vdCBhbGlnbiBhdXRvIHZh cmlhYmxlcyB0bworICAgYW55dGhpbmcgc3RyaWN0ZXIgdGhhbiB0aGVpciBkZWZhdWx0IGFs aWdubWVudC4KKworICAgVGhlIGZvbGxvd2luZyBkcmFmdCBDMVggcmVxdWlyZW1lbnRzIGFy ZSBub3Qgc3VwcG9ydGVkIGhlcmU6CisKKyAgICAgLSBJZiBBIGlzIHplcm8sIGFsaWduYXMg aGFzIG5vIGVmZmVjdC4KKyAgICAgLSBhbGlnbmFzIGNhbiBiZSB1c2VkIG11bHRpcGxlIHRp bWVzOyB0aGUgc3RyaWN0ZXN0IG9uZSB3aW5zLgorICAgICAtIGFsaWduYXMgKFRZUEUpIGlz IGVxdWl2YWxlbnQgdG8gYWxpZ25hcyAoYWxpZ25vZiAoVFlQRSkpLgorCisgICAqLworCisj aWYgX19HTlVDX18gfHwgX19JQk1DX18gfHwgX19JQk1DUFBfXyB8fCAweDUxMTAgPD0gX19T VU5QUk9fQworIyBkZWZpbmUgX0FsaWduYXMoYSkgX19hdHRyaWJ1dGVfXyAoKF9fYWxpZ25l ZF9fIChhKSkpCisjZWxpZiAxMzAwIDw9IF9NU0NfVkVSCisjIGRlZmluZSBfQWxpZ25hcyhh KSBfX2RlY2xzcGVjIChhbGlnbiAoYSkpCisjZW5kaWYKKyNpZmRlZiBfQWxpZ25hcworIyBk ZWZpbmUgYWxpZ25hcyBfQWxpZ25hcworIyBkZWZpbmUgX19hbGlnbmFzX2lzX2RlZmluZWQg MQorI2VuZGlmCisKKyNlbmRpZiAvKiBfR0xfU1REQUxJR05fSCAqLwoKPT09IG1vZGlmaWVk IGZpbGUgJ2xpYi9zdGRsaWIuaW4uaCcKLS0tIGxpYi9zdGRsaWIuaW4uaAkyMDExLTA3LTI0 IDIyOjE1OjQ3ICswMDAwCisrKyBsaWIvc3RkbGliLmluLmgJMjAxMS0xMS0wOCAwMToxMjow OCArMDAwMApAQCAtMjQ3LDcgKzI0Nyw3IEBACiAjZWxpZiBkZWZpbmVkIEdOVUxJQl9QT1NJ WENIRUNLCiAjIHVuZGVmIGdyYW50cHQKICMgaWYgSEFWRV9SQVdfREVDTF9HUkFOVFBUCi1f R0xfV0FSTl9PTl9VU0UgKHB0c25hbWUsICJncmFudHB0IGlzIG5vdCBwb3J0YWJsZSAtICIK K19HTF9XQVJOX09OX1VTRSAoZ3JhbnRwdCwgImdyYW50cHQgaXMgbm90IHBvcnRhYmxlIC0g IgogICAgICAgICAgICAgICAgICAidXNlIGdudWxpYiBtb2R1bGUgZ3JhbnRwdCBmb3IgcG9y dGFiaWxpdHkiKTsKICMgZW5kaWYKICNlbmRpZgpAQCAtNDIzLDYgKzQyMywyMiBAQAogIyBl bmRpZgogI2VuZGlmCiAKKyNpZiBAR05VTElCX1BPU0lYX09QRU5QVEAKKy8qIFJldHVybiBh biBGRCBvcGVuIHRvIHRoZSBtYXN0ZXIgc2lkZSBvZiBhIHBzZXVkby10ZXJtaW5hbC4gIEZs YWdzIHNob3VsZAorICAgaW5jbHVkZSBPX1JEV1IsIGFuZCBtYXkgYWxzbyBpbmNsdWRlIE9f Tk9DVFRZLiAgKi8KKyMgaWYgIUBIQVZFX1BPU0lYX09QRU5QVEAKK19HTF9GVU5DREVDTF9T WVMgKHBvc2l4X29wZW5wdCwgaW50LCAoaW50IGZsYWdzKSk7CisjIGVuZGlmCitfR0xfQ1hY QUxJQVNfU1lTIChwb3NpeF9vcGVucHQsIGludCwgKGludCBmbGFncykpOworX0dMX0NYWEFM SUFTV0FSTiAocG9zaXhfb3BlbnB0KTsKKyNlbGlmIGRlZmluZWQgR05VTElCX1BPU0lYQ0hF Q0sKKyMgdW5kZWYgcG9zaXhfb3BlbnB0CisjIGlmIEhBVkVfUkFXX0RFQ0xfUE9TSVhfT1BF TlBUCitfR0xfV0FSTl9PTl9VU0UgKHBvc2l4X29wZW5wdCwgInBvc2l4X29wZW5wdCBpcyBu b3QgcG9ydGFibGUgLSAiCisgICAgICAgICAgICAgICAgICJ1c2UgZ251bGliIG1vZHVsZSBw b3NpeF9vcGVucHQgZm9yIHBvcnRhYmlsaXR5Iik7CisjIGVuZGlmCisjZW5kaWYKKwogI2lm IEBHTlVMSUJfUFRTTkFNRUAKIC8qIFJldHVybiB0aGUgcGF0aG5hbWUgb2YgdGhlIHBzZXVk by10ZXJtaW5hbCBzbGF2ZSBhc3NvY2lhdGVkIHdpdGgKICAgIHRoZSBtYXN0ZXIgRkQgaXMg b3BlbiBvbiwgb3IgTlVMTCBvbiBlcnJvcnMuICAqLwoKPT09IG1vZGlmaWVkIGZpbGUgJ200 L2dsLWNvbXAubTQnCi0tLSBtNC9nbC1jb21wLm00CTIwMTEtMTAtMDcgMjE6MTU6MDAgKzAw MDAKKysrIG00L2dsLWNvbXAubTQJMjAxMS0xMC0xNyAwMToyMjoxOSArMDAwMApAQCAtNzYs NiArNzYsNyBAQAogICAjIENvZGUgZnJvbSBtb2R1bGUgc29ja2xlbjoKICAgIyBDb2RlIGZy b20gbW9kdWxlIHNzaXplX3Q6CiAgICMgQ29kZSBmcm9tIG1vZHVsZSBzdGF0OgorICAjIENv ZGUgZnJvbSBtb2R1bGUgc3RkYWxpZ246CiAgICMgQ29kZSBmcm9tIG1vZHVsZSBzdGRhcmc6 CiAgIGRubCBTb21lIGNvbXBpbGVycyAoZS5nLiwgQUlYIDUuMyBjYykgbmVlZCB0byBiZSBp biBjOTkgbW9kZQogICBkbmwgZm9yIHRoZSBidWlsdGluIHZhX2NvcHkgdG8gd29yay4gIFdp dGggQXV0b2NvbmYgMi42MCBvciBsYXRlciwKQEAgLTE4MCw2ICsxODEsNyBAQAogZ2xfU0lH TkFMX0gKIGdsX1RZUEVfU09DS0xFTl9UCiBndF9UWVBFX1NTSVpFX1QKK2dsX1NUREFMSUdO X0gKIGdsX1NUREFSR19ICiBBTV9TVERCT09MX0gKIGdsX1NURERFRl9ICkBAIC0zMTEsMTgg KzMxMywxOCBAQAogICBpZiB0ZXN0ICRIQVZFX1JFQURMSU5LID0gMCB8fCB0ZXN0ICRSRVBM QUNFX1JFQURMSU5LID0gMTsgdGhlbgogICAgIGZ1bmNfZ2xfZ251bGliX200Y29kZV9zdGF0 CiAgIGZpCi0gIGlmIHRlc3QgJGFjX2N2X2Z1bmNfc3RydG9pbWF4ID0gbm87IHRoZW4KLSAg ICBmdW5jX2dsX2dudWxpYl9tNGNvZGVfdmVyaWZ5Ci0gIGZpCiAgIGlmIHRlc3QgJGFjX2N2 X2Z1bmNfc3RydG9pbWF4ID0gbm8gJiYgdGVzdCAkYWNfY3ZfdHlwZV9sb25nX2xvbmdfaW50 ID0geWVzOyB0aGVuCiAgICAgZnVuY19nbF9nbnVsaWJfbTRjb2RlX3N0cnRvbGwKICAgZmkK LSAgaWYgdGVzdCAkYWNfY3ZfZnVuY19zdHJ0b3VtYXggPSBubzsgdGhlbgorICBpZiB0ZXN0 ICRhY19jdl9mdW5jX3N0cnRvaW1heCA9IG5vOyB0aGVuCiAgICAgZnVuY19nbF9nbnVsaWJf bTRjb2RlX3ZlcmlmeQogICBmaQogICBpZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvdW1heCA9 IG5vICYmIHRlc3QgJGFjX2N2X3R5cGVfdW5zaWduZWRfbG9uZ19sb25nX2ludCA9IHllczsg dGhlbgogICAgIGZ1bmNfZ2xfZ251bGliX200Y29kZV9zdHJ0b3VsbAogICBmaQorICBpZiB0 ZXN0ICRhY19jdl9mdW5jX3N0cnRvdW1heCA9IG5vOyB0aGVuCisgICAgZnVuY19nbF9nbnVs aWJfbTRjb2RlX3ZlcmlmeQorICBmaQogICBtNF9wYXR0ZXJuX2FsbG93KFteZ2xfR05VTElC X0VOQUJMRURfXSkKICAgQU1fQ09ORElUSU9OQUwoW2dsX0dOVUxJQl9FTkFCTEVEX2Rvc25h bWVdLCBbJGdsX2dudWxpYl9lbmFibGVkX2Rvc25hbWVdKQogICBBTV9DT05ESVRJT05BTChb Z2xfR05VTElCX0VOQUJMRURfYmU0NTNjZWM1ZWVjZjU3MzFhMjc0ZjJkZTdmMmRiMzZdLCBb JGdsX2dudWxpYl9lbmFibGVkX2JlNDUzY2VjNWVlY2Y1NzMxYTI3NGYyZGU3ZjJkYjM2XSkK QEAgLTUxMyw2ICs1MTUsNyBAQAogICBsaWIvc2lnbmFsLmluLmgKICAgbGliL3NpZ3Byb2Nt YXNrLmMKICAgbGliL3N0YXQuYworICBsaWIvc3RkYWxpZ24uaW4uaAogICBsaWIvc3RkYXJn LmluLmgKICAgbGliL3N0ZGJvb2wuaW4uaAogICBsaWIvc3RkZGVmLmluLmgKQEAgLTU2Myw2 ICs1NjYsNyBAQAogICBtNC9zc2l6ZV90Lm00CiAgIG00L3N0X2RtX21vZGUubTQKICAgbTQv c3RhdC5tNAorICBtNC9zdGRhbGlnbi5tNAogICBtNC9zdGRhcmcubTQKICAgbTQvc3RkYm9v bC5tNAogICBtNC9zdGRkZWZfaC5tNAoKPT09IG1vZGlmaWVkIGZpbGUgJ200L2luY2x1ZGVf bmV4dC5tNCcKLS0tIG00L2luY2x1ZGVfbmV4dC5tNAkyMDExLTA5LTI2IDIxOjMwOjE4ICsw MDAwCisrKyBtNC9pbmNsdWRlX25leHQubTQJMjAxMS0xMC0yNyAxOTo1MToyNiArMDAwMApA QCAtMSw0ICsxLDQgQEAKLSMgaW5jbHVkZV9uZXh0Lm00IHNlcmlhbCAyMgorIyBpbmNsdWRl X25leHQubTQgc2VyaWFsIDIzCiBkbmwgQ29weXJpZ2h0IChDKSAyMDA2LTIwMTEgRnJlZSBT b2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiBkbmwgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdh cmU7IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KIGRubCBnaXZlcyB1bmxpbWl0ZWQg cGVybWlzc2lvbiB0byBjb3B5IGFuZC9vciBkaXN0cmlidXRlIGl0LApAQCAtMjE5LDEyICsy MTksMTcgQEAKICAgICAgICAgICAgICAgICAgICBnbF9kaXJzZXBfcmVnZXg9J1svXFxdJwog ICAgICAgICAgICAgICAgICAgIDs7CiAgICAgICAgICAgICAgICAgICopCi0gICAgICAgICAg ICAgICAgICAgZ2xfZGlyc2VwX3JlZ2V4PScvJworICAgICAgICAgICAgICAgICAgIGdsX2Rp cnNlcF9yZWdleD0nXC8nCiAgICAgICAgICAgICAgICAgICAgOzsKICAgICAgICAgICAgICAg IGVzYWMKKyAgICAgICAgICAgICAgIGRubCBBIHNlZCBleHByZXNzaW9uIHRoYXQgdHVybnMg YSBzdHJpbmcgaW50byBhIGJhc2ljIHJlZ3VsYXIKKyAgICAgICAgICAgICAgIGRubCBleHBy ZXNzaW9uLCBmb3IgdXNlIHdpdGhpbiAiLy4uLi8iLgorICAgICAgICAgICAgICAgZ2xfbWFr ZV9saXRlcmFsX3JlZ2V4X3NlZD0ncyxbXSReXFwuKi9bXSxcXCYsZycKIGNoYW5nZXF1b3Rl KFssXSkKLSAgICAgICAgICAgICAgIGdsX2Fic29sdXRlX2hlYWRlcl9zZWQ9J1x8JyIke2ds X2RpcnNlcF9yZWdleH0iJ11tNF9kZWZuKFtnbF9IRUFERVJfTkFNRV0pW3x7Ci0gICAgICAg ICAgICAgICAgICAgc3wuKiJcKC4qJyIke2dsX2RpcnNlcF9yZWdleH0iJ11tNF9kZWZuKFtn bF9IRUFERVJfTkFNRV0pW1wpIi4qfFwxfAorICAgICAgICAgICAgICAgZ2xfaGVhZGVyX2xp dGVyYWxfcmVnZXg9YGVjaG8gJ11tNF9kZWZuKFtnbF9IRUFERVJfTkFNRV0pWycgXAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgc2VkIC1lICIkZ2xfbWFr ZV9saXRlcmFsX3JlZ2V4X3NlZCJgCisgICAgICAgICAgICAgICBnbF9hYnNvbHV0ZV9oZWFk ZXJfc2VkPSIvJHtnbF9kaXJzZXBfcmVnZXh9JHtnbF9oZWFkZXJfbGl0ZXJhbF9yZWdleH0v Iid7CisgICAgICAgICAgICAgICAgICAgcy8uKiJcKC4qJyIke2dsX2RpcnNlcF9yZWdleH0k e2dsX2hlYWRlcl9saXRlcmFsX3JlZ2V4fSInXCkiLiovXDEvCiBjaGFuZ2VxdW90ZSgsKWRu bAogICAgICAgICAgICAgICAgICAgIHN8Xi9bXi9dfC8vJnwKIGNoYW5nZXF1b3RlKFssXSlk bmwKCj09PSBtb2RpZmllZCBmaWxlICdtNC9wdGhyZWFkX3NpZ21hc2subTQnCi0tLSBtNC9w dGhyZWFkX3NpZ21hc2subTQJMjAxMS0wOS0wMyAyMzowODozMiArMDAwMAorKysgbTQvcHRo cmVhZF9zaWdtYXNrLm00CTIwMTEtMTAtMTcgMDE6MjI6MTkgKzAwMDAKQEAgLTEsNCArMSw0 IEBACi0jIHB0aHJlYWRfc2lnbWFzay5tNCBzZXJpYWwgMTIKKyMgcHRocmVhZF9zaWdtYXNr Lm00IHNlcmlhbCAxMwogZG5sIENvcHlyaWdodCAoQykgMjAxMSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sIEluYy4KIGRubCBUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbgogZG5sIGdpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9u IHRvIGNvcHkgYW5kL29yIGRpc3RyaWJ1dGUgaXQsCkBAIC02LDYgKzYsOCBAQAogCiBBQ19E RUZVTihbZ2xfRlVOQ19QVEhSRUFEX1NJR01BU0tdLAogWworICBBQ19SRVFVSVJFKFtnbF9T SUdOQUxfSF9ERUZBVUxUU10pCisKICAgQUNfQ0hFQ0tfRlVOQ1NfT05DRShbcHRocmVhZF9z aWdtYXNrXSkKICAgTElCX1BUSFJFQURfU0lHTUFTSz0KIAoKPT09IGFkZGVkIGZpbGUgJ200 L3N0ZGFsaWduLm00JwotLS0gbTQvc3RkYWxpZ24ubTQJMTk3MC0wMS0wMSAwMDowMDowMCAr MDAwMAorKysgbTQvc3RkYWxpZ24ubTQJMjAxMS0xMC0yNyAxOTozOTozMCArMDAwMApAQCAt MCwwICsxLDIyIEBACisjIENoZWNrIGZvciBzdGRhbGlnbi5oIHRoYXQgY29uZm9ybXMgdG8g QzF4LgorCitkbmwgQ29weXJpZ2h0IDIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJ bmMuCitkbmwgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb24KK2RubCBnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBjb3B5IGFu ZC9vciBkaXN0cmlidXRlIGl0LAorZG5sIHdpdGggb3Igd2l0aG91dCBtb2RpZmljYXRpb25z LCBhcyBsb25nIGFzIHRoaXMgbm90aWNlIGlzIHByZXNlcnZlZC4KKworIyBQcmVwYXJlIGZv ciBzdWJzdGl0dXRpbmcgPHN0ZGFsaWduLmg+IGlmIGl0IGlzIG5vdCBzdXBwb3J0ZWQuCisK K0FDX0RFRlVOKFtnbF9TVERBTElHTl9IXSwKK1sKKyAgQUNfQ0hFQ0tfSEVBREVSU19PTkNF KFtzdGRhbGlnbi5oXSkKKworICBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYWxpZ25faCA9 IHllczsgdGhlbgorICAgIFNUREFMSUdOX0g9JycKKyAgZWxzZQorICAgIFNUREFMSUdOX0g9 J3N0ZGFsaWduLmgnCisgIGZpCisKKyAgQUNfU1VCU1QoW1NUREFMSUdOX0hdKQorICBBTV9D T05ESVRJT05BTChbR0xfR0VORVJBVEVfU1REQUxJR05fSF0sIFt0ZXN0IC1uICIkU1REQUxJ R05fSCJdKQorXSkKCj09PSBtb2RpZmllZCBmaWxlICdtNC9zdGRsaWJfaC5tNCcKLS0tIG00 L3N0ZGxpYl9oLm00CTIwMTEtMDItMjUgMDc6MzY6MzcgKzAwMDAKKysrIG00L3N0ZGxpYl9o Lm00CTIwMTEtMTAtMjcgMTk6NTE6MjYgKzAwMDAKQEAgLTE5LDEwICsxOSwxMCBAQAogI2lm IEhBVkVfUkFORE9NX0gKICMgaW5jbHVkZSA8cmFuZG9tLmg+CiAjZW5kaWYKLSAgICBdXSwg W19FeGl0IGF0b2xsIGNhbm9uaWNhbGl6ZV9maWxlX25hbWUgZ2V0bG9hZGF2ZyBnZXRzdWJv cHQgZ3JhbnRwdCBta2R0ZW1wCi0gICAgbWtvc3RlbXAgbWtvc3RlbXBzIG1rc3RlbXAgbWtz dGVtcHMgcHRzbmFtZSByYW5kb21fciBpbml0c3RhdF9yIHNyYW5kb21fcgotICAgIHNldHN0 YXRlX3IgcmVhbHBhdGggcnBtYXRjaCBzZXRlbnYgc3RydG9kIHN0cnRvbGwgc3RydG91bGwg dW5sb2NrcHQKLSAgICB1bnNldGVudl0pCisgICAgXV0sIFtfRXhpdCBhdG9sbCBjYW5vbmlj YWxpemVfZmlsZV9uYW1lIGdldGxvYWRhdmcgZ2V0c3Vib3B0IGdyYW50cHQKKyAgICBpbml0 c3RhdGVfciBta2R0ZW1wIG1rb3N0ZW1wIG1rb3N0ZW1wcyBta3N0ZW1wIG1rc3RlbXBzIHBv c2l4X29wZW5wdAorICAgIHB0c25hbWUgcmFuZG9tX3IgcmVhbHBhdGggcnBtYXRjaCBzZXRl bnYgc2V0c3RhdGVfciBzcmFuZG9tX3Igc3RydG9kCisgICAgc3RydG9sbCBzdHJ0b3VsbCB1 bmxvY2twdCB1bnNldGVudl0pCiBdKQogCiBBQ19ERUZVTihbZ2xfU1RETElCX01PRFVMRV9J TkRJQ0FUT1JdLApAQCAtNTAsNiArNTAsNyBAQAogICBHTlVMSUJfTUtPU1RFTVBTPTA7ICAg ICBBQ19TVUJTVChbR05VTElCX01LT1NURU1QU10pCiAgIEdOVUxJQl9NS1NURU1QPTA7ICAg ICAgIEFDX1NVQlNUKFtHTlVMSUJfTUtTVEVNUF0pCiAgIEdOVUxJQl9NS1NURU1QUz0wOyAg ICAgIEFDX1NVQlNUKFtHTlVMSUJfTUtTVEVNUFNdKQorICBHTlVMSUJfUE9TSVhfT1BFTlBU PTA7ICBBQ19TVUJTVChbR05VTElCX1BPU0lYX09QRU5QVF0pCiAgIEdOVUxJQl9QVFNOQU1F PTA7ICAgICAgIEFDX1NVQlNUKFtHTlVMSUJfUFRTTkFNRV0pCiAgIEdOVUxJQl9QVVRFTlY9 MDsgICAgICAgIEFDX1NVQlNUKFtHTlVMSUJfUFVURU5WXSkKICAgR05VTElCX1JBTkRPTV9S PTA7ICAgICAgQUNfU1VCU1QoW0dOVUxJQl9SQU5ET01fUl0pCkBAIC03Niw2ICs3Nyw3IEBA CiAgIEhBVkVfTUtPU1RFTVBTPTE7ICAgICAgICAgIEFDX1NVQlNUKFtIQVZFX01LT1NURU1Q U10pCiAgIEhBVkVfTUtTVEVNUD0xOyAgICAgICAgICAgIEFDX1NVQlNUKFtIQVZFX01LU1RF TVBdKQogICBIQVZFX01LU1RFTVBTPTE7ICAgICAgICAgICBBQ19TVUJTVChbSEFWRV9NS1NU RU1QU10pCisgIEhBVkVfUE9TSVhfT1BFTlBUPTE7ICAgICAgIEFDX1NVQlNUKFtIQVZFX1BP U0lYX09QRU5QVF0pCiAgIEhBVkVfUFRTTkFNRT0xOyAgICAgICAgICAgIEFDX1NVQlNUKFtI QVZFX1BUU05BTUVdKQogICBIQVZFX1JBTkRPTV9IPTE7ICAgICAgICAgICBBQ19TVUJTVChb SEFWRV9SQU5ET01fSF0pCiAgIEhBVkVfUkFORE9NX1I9MTsgICAgICAgICAgIEFDX1NVQlNU KFtIQVZFX1JBTkRPTV9SXSkKCj09PSBtb2RpZmllZCBmaWxlICdtc2Rvcy9DaGFuZ2VMb2cn Ci0tLSBtc2Rvcy9DaGFuZ2VMb2cJMjAxMS0xMC0zMSAxNzozNzozOSArMDAwMAorKysgbXNk b3MvQ2hhbmdlTG9nCTIwMTEtMTEtMDggMDY6MzU6MzcgKzAwMDAKQEAgLTEsMyArMSwxMCBA QAorMjAxMS0xMS0wOCAgUGF1bCBFZ2dlcnQgIDxlZ2dlcnRAY3MudWNsYS5lZHU+CisKKwlV c2UgR251bGliIHN0ZGFsaWduIG1vZHVsZSAoQnVnIzk3NzIsIEJ1ZyM5OTYwKS4KKwkqIHNl ZDJ2Mi5pbnAgKEhBVkVfQVRUUklCVVRFX0FMSUdORUQpOiBSZW1vdmUgZWRpdC4KKwkqIHNl ZGxpYm1rLmlucCAoU1REQUxJR05fSCwgQEdMX0dFTkVSQVRFX1NUREFMSUdOX0hfVFJVRUAp CisJKEdMX0dFTkVSQVRFX1NUREFMSUdOX0hfRkFMU0UpOiBOZXcgZWRpdHMuCisKIDIwMTEt MTAtMzEgIEVsaSBaYXJldHNraWkgIDxlbGl6QGdudS5vcmc+CiAKIAkqIHNlZDN2Mi5pbnAg KGluc3JjZGlyKTogQ29tbWVudCBvdXQgZGVmaW5pdGlvbi4KCj09PSBtb2RpZmllZCBmaWxl ICdtc2Rvcy9zZWQydjIuaW5wJwotLS0gbXNkb3Mvc2VkMnYyLmlucAkyMDExLTEwLTMxIDAy OjI1OjAxICswMDAwCisrKyBtc2Rvcy9zZWQydjIuaW5wCTIwMTEtMTEtMDEgMDU6MDM6NTYg KzAwMDAKQEAgLTM1LDcgKzM1LDYgQEAKIC9eI3VuZGVmIEhBVkVfRlJFWFAgKiQvcy9eLiok LyNkZWZpbmUgSEFWRV9GUkVYUCAxLwogL14jdW5kZWYgSEFWRV9GTU9EICokL3MvXi4qJC8j ZGVmaW5lIEhBVkVfRk1PRCAxLwogL14jdW5kZWYgSEFWRV9SSU5UICokL3MvXi4qJC8jZGVm aW5lIEhBVkVfUklOVCAxLwotL14jdW5kZWYgSEFWRV9BVFRSSUJVVEVfQUxJR05FRCAqJC9z L14uKiQvI2RlZmluZSBIQVZFX0FUVFJJQlVURV9BTElHTkVEIDEvCiAvXiN1bmRlZiBIQVZF X0M5OV9TVFJUT0xEICokL3MvXi4qJC8jZGVmaW5lIEhBVkVfQzk5X1NUUlRPTEQgMS8KIC9e I3VuZGVmIEhBVkVfQ0JSVCAqJC9zL14uKiQvI2RlZmluZSBIQVZFX0NCUlQgMS8KIC9eI3Vu ZGVmIEhBVkVfRElGRlRJTUUgKiQvcy9eLiokLyNkZWZpbmUgSEFWRV9ESUZGVElNRSAxLwpA QCAtMTE5LDQgKzExOCwzIEBACiAjIG1pZ2h0IGJlIGRlZmluZWQgaW4gc3lzL2NvbmZpZy5o IHdlIGluY2x1ZGUgYXQgdGhlIHRvcCBvZiBjb25maWcuaC4KIC9eI3VuZGVmIEJTVFJJTkcv c3wjdW5kZWZ8IyB1bmRlZnwKIC9eI3VuZGVmIC4qJC9zfF4uKiR8LyogJiAqL3wKLQoKPT09 IG1vZGlmaWVkIGZpbGUgJ21zZG9zL3NlZGxpYm1rLmlucCcKLS0tIG1zZG9zL3NlZGxpYm1r LmlucAkyMDExLTA5LTI5IDEyOjAwOjE4ICswMDAwCisrKyBtc2Rvcy9zZWRsaWJtay5pbnAJ MjAxMS0xMC0xNyAwMToyMjoxOSArMDAwMApAQCAtMjcsNyArMjcsNyBAQAogIyAgICBvdGhl cndpc2UgZWRpdCB0aGVtIHRvIHplcm86CiAjCiAjICAgICAvXlJFUExBQ0VfQ0FMTE9DICo9 L3MvQFJFUExBQ0VfQ0FMTE9DQC8wLwotIyAKKyMKICMgIC4gSWYgdGhlIG1vZHVsZSBpcyBh IGhlYWRlciBvciBhZGRzIGhlYWRlcnMsIGVkaXQgdGhlIGNvcnJlc3BvbmRpbmcKICMgICAg dmFyaWFibGUgdG8gZWl0aGVyIGFuIGVtcHR5IHZhbHVlIG9yIHRvIHRoZSBuYW1lIG9mIHRo ZSBoZWFkZXIuCiAjICAgIEV4YW1wbGVzOgpAQCAtNTQ3LDYgKzU0Nyw3IEBACiAvXlNJWkVf VF9TVUZGSVggKj0vcy9AU0laRV9UX1NVRkZJWEAvdS8KIC9eQUxMT0NBX0ggKj0vcy9AW15A XG5dKkAvYWxsb2NhLmgvCiAvXlNUREJPT0xfSCAqPS9zL0BbXkBcbl0qQC8vCisvXlNUREFM SUdOX0ggKj0vcy9AW15AXG5dKkAvc3RkYWxpZ24uaC8KIC9eU1REQVJHX0ggKj0vcy9AW15A XG5dKkAvLwogL15TVERERUZfSCAqPS9zL0BbXkBcbl0qQC8vCiAvXlNURElOVF9IICo9L3Mv QFteQFxuXSpAL3N0ZGludC5oLwpAQCAtNjAwLDYgKzYwMSw4IEBACiBzL15AR0xfR0VORVJB VEVfQUxMT0NBX0hfRkFMU0VAL1wjLwogcy9eQEdMX0dFTkVSQVRFX1NUREJPT0xfSF9UUlVF QC9cIy8KIHMvXkBHTF9HRU5FUkFURV9TVERCT09MX0hfRkFMU0VALy8KK3MvXkBHTF9HRU5F UkFURV9TVERBTElHTl9IX1RSVUVALy8KK3MvXkBHTF9HRU5FUkFURV9TVERBTElHTl9IX0ZB TFNFQC9cIy8KIHMvXkBHTF9HRU5FUkFURV9TVERBUkdfSF9UUlVFQC9cIy8KIHMvXkBHTF9H RU5FUkFURV9TVERBUkdfSF9GQUxTRUAvXCMvCiBzL15AR0xfR0VORVJBVEVfU1REREVGX0hf VFJVRUAvXCMvCgo9PT0gbW9kaWZpZWQgZmlsZSAnbnQvQ2hhbmdlTG9nJwotLS0gbnQvQ2hh bmdlTG9nCTIwMTEtMTEtMDUgMjI6MzM6NDQgKzAwMDAKKysrIG50L0NoYW5nZUxvZwkyMDEx LTExLTA4IDA2OjM1OjM3ICswMDAwCkBAIC0xLDMgKzEsOCBAQAorMjAxMS0xMS0wOCAgUGF1 bCBFZ2dlcnQgIDxlZ2dlcnRAY3MudWNsYS5lZHU+CisKKwlVc2UgR251bGliIHN0ZGFsaWdu IG1vZHVsZSAoQnVnIzk3NzIsIEJ1ZyM5OTYwKS4KKwkqIGNvbmZpZy5udCAoSEFWRV9BVFRS SUJVVEVfQUxJR05FRCk6IFJlbW92ZS4KKwogMjAxMS0xMS0wNSAgQ2hyaXN0b3BoIFNjaG9s dGVzICA8Y3NjaG9sMjExMkBnb29nbGVtYWlsLmNvbT4KIAogCSogaW5jL3N0ZGludC5oIChV SU5UNjRfTUFYLCBVSU5UNjRfTUlOLCBJTlQ2NF9NSU4sIFVJTlRNQVhfTUFYKQoKPT09IG1v ZGlmaWVkIGZpbGUgJ250L2NvbmZpZy5udCcKLS0tIG50L2NvbmZpZy5udAkyMDExLTExLTA1 IDE3OjE2OjAxICswMDAwCisrKyBudC9jb25maWcubnQJMjAxMS0xMS0wNyAwNTo1OToyOSAr MDAwMApAQCAtMjc4LDEzICsyNzgsNiBAQAogCiAvKiBQcmVwcm9jZXNzb3IgbWFjcm9zIG5l ZWRlZCBmb3IgZ251bGliIGltcG9ydHMuICAqLwogCi0vKiBEZWZpbmUgdG8gMSBpZiBHQ0Mt c3R5bGUgX19hdHRyaWJ1dGVfXyAoKF9fYWxpZ25lZF9fIChleHByKSkpIHdvcmtzLiAqLwot I2lmZGVmIF9fR05VQ19fCi0jZGVmaW5lIEhBVkVfQVRUUklCVVRFX0FMSUdORUQgMQotI2Vs c2UKLSN1bmRlZiBIQVZFX0FUVFJJQlVURV9BTElHTkVECi0jZW5kaWYKLQogLyogRGVmaW5l IHRvIDEgaWYgc3RydG9sZCBjb25mb3JtcyB0byBDOTkuICovCiAjaWZkZWYgX19HTlVDX18K ICNkZWZpbmUgSEFWRV9DOTlfU1RSVE9MRCAxCgo9PT0gbW9kaWZpZWQgZmlsZSAnc3JjL0No YW5nZUxvZycKLS0tIHNyYy9DaGFuZ2VMb2cJMjAxMS0xMS0wNyAxNzowNDowMSArMDAwMAor Kysgc3JjL0NoYW5nZUxvZwkyMDExLTExLTA4IDA2OjM1OjM3ICswMDAwCkBAIC0xLDMgKzEs MTQgQEAKKzIwMTEtMTEtMDggIFBhdWwgRWdnZXJ0ICA8ZWdnZXJ0QGNzLnVjbGEuZWR1Pgor CisJVXNlIEdudWxpYiBzdGRhbGlnbiBtb2R1bGUgKEJ1ZyM5NzcyLCBCdWcjOTk2MCkuCisJ KiBhbGxvYy5jIChYTUFMTE9DX0JBU0VfQUxJR05NRU5ULCBHQ19MSVNQX09CSkVDVF9BTElH Tk1FTlQpCisJKEdDX1BPSU5URVJfQUxJR05NRU5ULCBwdXJlX2FsbG9jKTogU2ltcGxpZnkg YnkgdXNpbmcgYWxpZ25vZi4KKwkocHVyZV9hbGxvYykgWyEgVVNFX0xTQl9UQUddOiBEb24n dCBvdmVyLWFsaWduIEVNQUNTX0lOVCB2YWx1ZXMuCisJKiBsaXNwLmg6IEluY2x1ZGUgPHN0 ZGFsaWduLmg+LgorCShERUNMX0FMSUdOKTogU2ltcGxpZnkgYnkgdXNpbmcgYWxpZ25hcy4K KwlQb3J0IHRvIE1TVkMsIGJ5IHVzaW5nIEFMSUdOX0dDVFlQRUJJVFMuCisJKEFMSUdOX0dD VFlQRUJJVFMpOiBOZXcgbWFjcm8uCisKIDIwMTEtMTEtMDcgIEp1YW5tYSBCYXJyYW5xdWVy byAgPGxla2t0dUBnbWFpbC5jb20+CiAKIAkqIGxpc3AuaCAoc3ltc19vZl9hYmJyZXYpOiBS ZW1vdmUgZGVjbGFyYXRpb24uCgo9PT0gbW9kaWZpZWQgZmlsZSAnc3JjL2FsbG9jLmMnCi0t LSBzcmMvYWxsb2MuYwkyMDExLTExLTA3IDA1OjM3OjQ5ICswMDAwCisrKyBzcmMvYWxsb2Mu YwkyMDExLTExLTA3IDA1OjU5OjI5ICswMDAwCkBAIC01MTMsMTIgKzUxMyw3IEBACiAgICBo b2xkIGEgc2l6ZV90IHZhbHVlIGFuZCAoMikgdGhlIGhlYWRlciBzaXplIGlzIGEgbXVsdGlw bGUgb2YgdGhlCiAgICBhbGlnbm1lbnQgdGhhdCBFbWFjcyBuZWVkcyBmb3IgQyB0eXBlcyBh bmQgZm9yIFVTRV9MU0JfVEFHLiAgKi8KICNkZWZpbmUgWE1BTExPQ19CQVNFX0FMSUdOTUVO VAkJCQlcCi0gIG9mZnNldG9mICgJCQkJCQlcCi0gICAgc3RydWN0IHsJCQkJCQlcCi0gICAg ICB1bmlvbiB7IGxvbmcgZG91YmxlIGQ7IGludG1heF90IGk7IHZvaWQgKnA7IH0gdTsJXAot ICAgICAgY2hhciBjOwkJCQkJCVwKLSAgICB9LAkJCQkJCQlcCi0gICAgYykKKyAgYWxpZ25v ZiAodW5pb24geyBsb25nIGRvdWJsZSBkOyBpbnRtYXhfdCBpOyB2b2lkICpwOyB9KQogI2lm ZGVmIFVTRV9MU0JfVEFHCiAvKiBBIGNvbW1vbiBtdWx0aXBsZSBvZiB0aGUgcG9zaXRpdmUg aW50ZWdlcnMgQSBhbmQgQi4gIElkZWFsbHkgdGhpcwogICAgd291bGQgYmUgdGhlIGxlYXN0 IGNvbW1vbiBtdWx0aXBsZSwgYnV0IHRoZXJlJ3Mgbm8gd2F5IHRvIGRvIHRoYXQKQEAgLTQy NDEsMTUgKzQyMzYsMTUgQEAKIH0KIAogCi0vKiBBbGlnbm1lbnQgb2YgTGlzcF9PYmplY3Qg YW5kIHBvaW50ZXIgdmFsdWVzLiAgVXNlIG9mZnNldG9mLCBhcyBpdAorLyogQWxpZ25tZW50 IG9mIExpc3BfT2JqZWN0IGFuZCBwb2ludGVyIHZhbHVlcy4gIFVzZSBhbGlnbm9mLCBhcyBp dAogICAgc29tZXRpbWVzIHJldHVybnMgYSBzbWFsbGVyIGFsaWdubWVudCB0aGFuIEdDQydz IF9fYWxpZ25vZl9fIGFuZAogICAgbWFya19tZW1vcnkgbWlnaHQgbWlzcyBvYmplY3RzIGlm IF9fYWxpZ25vZl9fIHdlcmUgdXNlZC4gIEZvcgogICAgZXhhbXBsZSwgb24geDg2IHdpdGgg V0lERV9FTUFDU19JTlQsIF9fYWxpZ25vZl9fIChMaXNwX09iamVjdCkgaXMgOAogICAgYnV0 IEdDX0xJU1BfT0JKRUNUX0FMSUdOTUVOVCBzaG91bGQgYmUgNC4gICovCiAjaWZuZGVmIEdD X0xJU1BfT0JKRUNUX0FMSUdOTUVOVAotIyBkZWZpbmUgR0NfTElTUF9PQkpFQ1RfQUxJR05N RU5UIG9mZnNldG9mIChzdHJ1Y3Qge2NoYXIgYTsgTGlzcF9PYmplY3QgYjt9LCBiKQorIyBk ZWZpbmUgR0NfTElTUF9PQkpFQ1RfQUxJR05NRU5UIGFsaWdub2YgKExpc3BfT2JqZWN0KQog I2VuZGlmCi0jZGVmaW5lIEdDX1BPSU5URVJfQUxJR05NRU5UIG9mZnNldG9mIChzdHJ1Y3Qg e2NoYXIgYTsgdm9pZCAqYjt9LCBiKQorI2RlZmluZSBHQ19QT0lOVEVSX0FMSUdOTUVOVCBh bGlnbm9mICh2b2lkICopCiAKIC8qIE1hcmsgTGlzcCBvYmplY3RzIHJlZmVyZW5jZWQgZnJv bSB0aGUgYWRkcmVzcyByYW5nZSBTVEFSVCtPRkZTRVQuLkVORAogICAgb3IgRU5EK09GRlNF VC4uU1RBUlQuICovCkBAIC00NjY4LDE3ICs0NjYzLDExIEBACiAjaWZkZWYgVVNFX0xTQl9U QUcKICAgc2l6ZV90IGFsaWdubWVudCA9ICgxIDw8IEdDVFlQRUJJVFMpOwogI2Vsc2UKLSAg c2l6ZV90IGFsaWdubWVudCA9IHNpemVvZiAoRU1BQ1NfSU5UKTsKKyAgc2l6ZV90IGFsaWdu bWVudCA9IGFsaWdub2YgKEVNQUNTX0lOVCk7CiAKICAgLyogR2l2ZSBMaXNwX0Zsb2F0cyBh biBleHRyYSBhbGlnbm1lbnQuICAqLwogICBpZiAodHlwZSA9PSBMaXNwX0Zsb2F0KQotICAg IHsKLSNpZiBkZWZpbmVkIF9fR05VQ19fICYmIF9fR05VQ19fID49IDIKLSAgICAgIGFsaWdu bWVudCA9IF9fYWxpZ25vZiAoc3RydWN0IExpc3BfRmxvYXQpOwotI2Vsc2UKLSAgICAgIGFs aWdubWVudCA9IHNpemVvZiAoc3RydWN0IExpc3BfRmxvYXQpOwotI2VuZGlmCi0gICAgfQor ICAgIGFsaWdubWVudCA9IGFsaWdub2YgKHN0cnVjdCBMaXNwX0Zsb2F0KTsKICNlbmRpZgog CiAgYWdhaW46Cgo9PT0gbW9kaWZpZWQgZmlsZSAnc3JjL2xpc3AuaCcKLS0tIHNyYy9saXNw LmgJMjAxMS0xMS0wNyAxNzowNDowMSArMDAwMAorKysgc3JjL2xpc3AuaAkyMDExLTExLTA4 IDAxOjA3OjE4ICswMDAwCkBAIC0yMCw2ICsyMCw3IEBACiAjaWZuZGVmIEVNQUNTX0xJU1Bf SAogI2RlZmluZSBFTUFDU19MSVNQX0gKIAorI2luY2x1ZGUgPHN0ZGFsaWduLmg+CiAjaW5j bHVkZSA8c3RkYXJnLmg+CiAjaW5jbHVkZSA8c3RkZGVmLmg+CiAjaW5jbHVkZSA8aW50dHlw ZXMuaD4KQEAgLTE2MywxOCArMTY0LDggQEAKIC8qIEZpcnN0LCB0cnkgYW5kIGRlZmluZSBE RUNMX0FMSUdOKHR5cGUsdmFyKSB3aGljaCBkZWNsYXJlcyBhIHN0YXRpYwogICAgdmFyaWFi bGUgVkFSIG9mIHR5cGUgVFlQRSB3aXRoIHRoZSBhZGRlZCByZXF1aXJlbWVudCB0aGF0IGl0 IGJlCiAgICBUWVBFQklUUy1hbGlnbmVkLiAgKi8KLSNpZm5kZWYgTk9fREVDTF9BTElHTgot IyBpZm5kZWYgREVDTF9BTElHTgotIyAgaWYgSEFWRV9BVFRSSUJVVEVfQUxJR05FRAotIyAg IGRlZmluZSBERUNMX0FMSUdOKHR5cGUsIHZhcikgXAotICAgICB0eXBlIF9fYXR0cmlidXRl X18gKChfX2FsaWduZWRfXyAoMSA8PCBHQ1RZUEVCSVRTKSkpIHZhcgotIyAgZWxpZiBkZWZp bmVkKF9NU0NfVkVSKQotIyAgIGRlZmluZSBERUNMX0FMSUdOKHR5cGUsIHZhcikgXAotICAg ICB0eXBlIF9fZGVjbHNwZWMoYWxpZ24oMSA8PCBHQ1RZUEVCSVRTKSkgdmFyCi0jICBlbHNl Ci0gICAgIC8qIFdoYXQgZGlyZWN0aXZlcyBkbyBvdGhlciBjb21waWxlcnMgdXNlPyAgKi8K LSMgIGVuZGlmCi0jIGVuZGlmCisjaWZkZWYgYWxpZ25hcworIyBkZWZpbmUgREVDTF9BTElH Tih0eXBlLCB2YXIpIHR5cGUgYWxpZ25hcyAoQUxJR05fR0NUWVBFQklUUykgdmFyCiAjZW5k aWYKIAogLyogTGV0J3MgVVNFX0xTQl9UQUcgb24gc3lzdGVtcyB3aGVyZSB3ZSBrbm93IG1h bGxvYyByZXR1cm5zIG11bHQtb2YtOC4gICovCkBAIC0zMDIsNiArMjkzLDEwIEBACiAKICNp Zm5kZWYgR0NUWVBFQklUUwogI2RlZmluZSBHQ1RZUEVCSVRTIDMKKyNkZWZpbmUgQUxJR05f R0NUWVBFQklUUyA4IC8qIFRoaXMgbXVzdCBiZSBhbiBpbnRlZ2VyIGNvbnN0YW50LCBmb3Ig TVNWQy4gICovCisjZW5kaWYKKyNpZiAxIDw8IEdDVFlQRUJJVFMgIT0gQUxJR05fR0NUWVBF QklUUworIyBlcnJvciAiQUxJR05fR0NUWVBFQklUUyBpcyB3cm9uZyEiCiAjZW5kaWYKIAog LyogVGhlc2UgdmFsdWVzIGFyZSBvdmVycmlkZGVuIGJ5IHRoZSBtLSBmaWxlIG9uIHNvbWUg bWFjaGluZXMuICAqLwo= --------------060707080900070208090306-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Nov 2011 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132077138622386 (code B ref 9960); Tue, 08 Nov 2011 16:57:02 +0000 Received: (at 9960) by debbugs.gnu.org; 8 Nov 2011 16:56:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNoyH-0005p0-Qw for submit@debbugs.gnu.org; Tue, 08 Nov 2011 11:56:26 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNoyF-0005os-Ry for 9960@debbugs.gnu.org; Tue, 08 Nov 2011 11:56:25 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LUC00A00PJ98G00@a-mtaout23.012.net.il> for 9960@debbugs.gnu.org; Tue, 08 Nov 2011 18:53:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.42.212]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUC00A5JPKX7E30@a-mtaout23.012.net.il>; Tue, 08 Nov 2011 18:53:23 +0200 (IST) Date: Tue, 08 Nov 2011 18:51:21 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83lirqimly.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83ty6fj2ev.fsf@gnu.org> X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.7 (-) > From: Fabrice Popineau > 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2011 19:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132095501510009 (code B ref 9960); Thu, 10 Nov 2011 19:57:01 +0000 Received: (at 9960) by debbugs.gnu.org; 10 Nov 2011 19:56:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROak2-0002bN-F0 for submit@debbugs.gnu.org; Thu, 10 Nov 2011 14:56:55 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROajz-0002b9-Gq for 9960@debbugs.gnu.org; Thu, 10 Nov 2011 14:56:53 -0500 Received: by bkbzv15 with SMTP id zv15so2571147bkb.3 for <9960@debbugs.gnu.org>; Thu, 10 Nov 2011 11:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=xt+G4OwIGP/gVwS7OFOrMEBMWEmy1ugEcmvaTe654Rg=; b=tRG9TQdyAJ0Rej9TB8O4KEtxnEpdIkfAvGUlIqCJVHA96lPZKPAxVFAFtm+k7Rlc19 BhCxUwk3oa/NcsnuI/T3XVtcYkUdjntVA5l0oHznPJfnm9HjhGfj5E0RxPV19fPbXv6N xY5leEdwtM5Z3bxQucCXvTBWD36m40zqE9eQQ= Received: by 10.205.114.65 with SMTP id ez1mr5960889bkc.99.1320954993193; Thu, 10 Nov 2011 11:56:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Thu, 10 Nov 2011 11:56:11 -0800 (PST) In-Reply-To: <83sjlzj25l.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Fabrice Popineau Date: Thu, 10 Nov 2011 20:56:11 +0100 X-Google-Sender-Auth: h8EBc3cDRsLJnUzYIfo-5pyu5d0 Message-ID: Content-Type: multipart/mixed; boundary=14dae9c097fe22329d04b166cd9c X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --14dae9c097fe22329d04b166cd9c Content-Type: multipart/alternative; boundary=14dae9c097fe22329904b166cd9a --14dae9c097fe22329904b166cd9a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/11/7 Eli Zaretskii > Will this work: > > #define ALIGN_GCTYPEBITS 8 > #if (1 << GCTYPEBITS) !=3D 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 --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --14dae9c097fe22329904b166cd9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/11/7 Eli Zaretskii <eliz@gnu.org>= ;
Will this work:

=A0#define ALIGN_GCTYPEBITS 8
=A0#if (1 << GCTYPEBITS) !=3D ALIGN_GCTYPEBITS
=A0#error ALIGN_GCTYPEBITS is wrong!
=A0#endif
=A0#define DECL_ALIGN(type, var) \
=A0 =A0 =A0 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. =A0WDYT?

Sure. feel free to adapt on the basis of the attache= d patch.
Status is :=A0
- completely functional 32 bits versi= on with xpm, gif, jpeg, tiff. Able to boostrap itself.
- the 64 b= its 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 c= ompiling image.c for example.

Feel free to comment and adapt for the release version.=

Fabrice



--
Fabrice Popineau
-----------------------------
SUPELEC
D=E9partement Informatique
3, rue Joliot C= urie
91192 Gif/Yvette Cedex
Tel direct : +33 = (0) 169851950
-----------------= -------------


--14dae9c097fe22329904b166cd9a-- --14dae9c097fe22329d04b166cd9c Content-Type: application/octet-stream; name="emacs-24-3.diff" Content-Disposition: attachment; filename="emacs-24-3.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_guu6bqpd0 PT09IG1vZGlmaWVkIGZpbGUgJ2J1aWxkLWF1eC9tb3ZlLWlmLWNoYW5nZScgKHByb3BlcnRpZXMg Y2hhbmdlZDogK3ggdG8gLXgpCj09PSBtb2RpZmllZCBmaWxlICdsaWItc3JjL2VtYWNzY2xpZW50 LmMnCi0tLSBsaWItc3JjL2VtYWNzY2xpZW50LmMJMjAxMS0xMC0yNyAwMDo1OToyMSArMDAwMAor KysgbGliLXNyYy9lbWFjc2NsaWVudC5jCTIwMTEtMTEtMTAgMTc6NDA6MjkgKzAwMDAKQEAgLTE2 MzUsNyArMTYzNSw5IEBACiAgIC8qIFNlbmQgb3ZlciBvdXIgZW52aXJvbm1lbnQgYW5kIGN1cnJl bnQgZGlyZWN0b3J5LiAqLwogICBpZiAoIWN1cnJlbnRfZnJhbWUpCiAgICAgeworI2lmbmRlZiBf TVNDX1ZFUgogICAgICAgZXh0ZXJuIGNoYXIgKiplbnZpcm9uOworI2VuZGlmCiAgICAgICBpbnQg aTsKICAgICAgIGZvciAoaSA9IDA7IGVudmlyb25baV07IGkrKykKICAgICAgICAgewoKPT09IG1v ZGlmaWVkIGZpbGUgJ2xpYi1zcmMvbWFrZWZpbGUudzMyLWluJwotLS0gbGliLXNyYy9tYWtlZmls ZS53MzItaW4JMjAxMS0wNy0wNyAwMTozMjo1NiArMDAwMAorKysgbGliLXNyYy9tYWtlZmlsZS53 MzItaW4JMjAxMS0xMS0wOCAxODoyMzowMSArMDAwMApAQCAtMjMsNyArMjMsNyBAQAogCiBMT0NB TF9GTEFHUwk9IC1EV0lORE9XU05UIC1ERE9TX05UIC1ETk9fTERBVj0xIFwKIAkJICAtRE5PX0FS Q0hJVkVTPTEgLURIQVZFX0NPTkZJR19IPTEgLUkuLi9saWIgXAotCQkgIC1JLi4vbnQvaW5jIC1J Li4vc3JjCisJCSAgLUkuLi9udC9pbmMgLUkuLi9zcmMgJChFTUFDU19FWFRSQV9DX0ZMQUdTKQog CiBMSUJTIAkJPSAkKEJBU0VfTElCUykgJChBRFZBUEkzMikKIAoKPT09IG1vZGlmaWVkIGZpbGUg J2xpYi9zdHJmdGltZS5jJwotLS0gbGliL3N0cmZ0aW1lLmMJMjAxMS0wMy0zMSAwNDoyNDowMyAr MDAwMAorKysgbGliL3N0cmZ0aW1lLmMJMjAxMS0xMS0xMCAxNzozOTozNyArMDAwMApAQCAtMzYs OSArMzYsMTQgQEAKICNpbmNsdWRlIDxjdHlwZS5oPgogI2luY2x1ZGUgPHRpbWUuaD4KIAorI2lm ZGVmIF9NU0NfVkVSCisjZGVmaW5lIHR6bmFtZSBfdHpuYW1lCisjZWxzZQogI2lmIEhBVkVfVFpO QU1FICYmICFIQVZFX0RFQ0xfVFpOQU1FCiBleHRlcm4gY2hhciAqdHpuYW1lW107CiAjZW5kaWYK KyNlbmRpZgorCiAKIC8qIERvIG11bHRpYnl0ZSBwcm9jZXNzaW5nIGlmIG11bHRpYnl0ZXMgYXJl IHN1cHBvcnRlZCwgdW5sZXNzCiAgICBtdWx0aWJ5dGUgc2VxdWVuY2VzIGFyZSBzYWZlIGluIGZv cm1hdHMuICBNdWx0aWJ5dGUgc2VxdWVuY2VzIGFyZQoKPT09IG1vZGlmaWVkIGZpbGUgJ2xpc3Av YmluZGluZ3MuZWwnCi0tLSBsaXNwL2JpbmRpbmdzLmVsCTIwMTEtMTAtMDggMTY6Mzc6NDYgKzAw MDAKKysrIGxpc3AvYmluZGluZ3MuZWwJMjAxMS0xMS0xMCAxNzo0OTozNSArMDAwMApAQCAtODI0 LDEzICs4MjQsMTMgQEAKIDs7IERlZmluZSBjb250cm9sLWRpZ2l0cy4KIChsZXQgKChpID8wKSkK ICAgKHdoaWxlICg8PSBpID85KQotICAgIChkZWZpbmUta2V5IGdsb2JhbC1tYXAgKHJlYWQgKGZv cm1hdCAiWz9cXEMtJWNdIiBpKSkgJ2RpZ2l0LWFyZ3VtZW50KQorOyAgICAoZGVmaW5lLWtleSBn bG9iYWwtbWFwIChyZWFkIChmb3JtYXQgIls/XFxDLSVjXSIgaSkpICdkaWdpdC1hcmd1bWVudCkK ICAgICAoc2V0cSBpICgxKyBpKSkpKQogKGRlZmluZS1rZXkgZ2xvYmFsLW1hcCBbP1xDLS1dICdu ZWdhdGl2ZS1hcmd1bWVudCkKIDs7IERlZmluZSBjb250cm9sLW1ldGEtZGlnaXRzLgogKGxldCAo KGkgPzApKQogICAod2hpbGUgKDw9IGkgPzkpCi0gICAgKGRlZmluZS1rZXkgZXNjLW1hcCAocmVh ZCAoZm9ybWF0ICJbP1xcQy0lY10iIGkpKSAnZGlnaXQtYXJndW1lbnQpCis7ICAgIChkZWZpbmUt a2V5IGVzYy1tYXAgKHJlYWQgKGZvcm1hdCAiWz9cXEMtJWNdIiBpKSkgJ2RpZ2l0LWFyZ3VtZW50 KQogICAgIChzZXRxIGkgKDErIGkpKSkpCiAoZGVmaW5lLWtleSBnbG9iYWwtbWFwIFs/XEMtXE0t LV0gJ25lZ2F0aXZlLWFyZ3VtZW50KQogCgo9PT0gbW9kaWZpZWQgZmlsZSAnbnQvY29uZmlnLm50 JwotLS0gbnQvY29uZmlnLm50CTIwMTEtMTEtMDUgMTc6MTY6MDEgKzAwMDAKKysrIG50L2NvbmZp Zy5udAkyMDExLTExLTEwIDE3OjQyOjIyICswMDAwCkBAIC0zMDMsNiArMzAzLDEwIEBACiAvKiBE ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGxvY2FsdGltZV9yJyBmdW5jdGlvbi4gKi8KICN1 bmRlZiBIQVZFX0xPQ0FMVElNRV9SCiAKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBk ZWNsYXJhdGlvbiBvZiBgc3RydG9sbCcsIGFuZCB0byAwIGlmIHlvdQorICAgZG9uJ3QuICovCisj ZGVmaW5lIEhBVkVfREVDTF9TVFJUT0xMIDEKKwogLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg dGhlIGRlY2xhcmF0aW9uIG9mIGBzdHJ0b3VsbCcsIGFuZCB0byAwIGlmIHlvdQogICAgZG9uJ3Qu ICovCiAjZGVmaW5lIEhBVkVfREVDTF9TVFJUT1VMTCAxCkBAIC0zNTMsOCArMzU3LDggQEAKIC8q IEEgdmFfY29weSByZXBsYWNlbWVudCBmb3IgTVNWQy4gICovCiAjaWZkZWYgX01TQ19WRVIKICMg aWZkZWYgX1dJTjY0Ci0jICBpZm5kZWYgdmFfY29weQotIyAgIGVycm9yICJ2YV9jb3B5IGlzIG5l ZWRlZCwgYnV0IG5vdCBkZWZpbmVkISIKKyMgIGlmbmRlZiB2YV9jb3B5ICAgICAgICAgICAgICAg LyogTmVlZCB0byBiZSBjaGVja2VkICg/KSAqLworIyAgIGRlZmluZSB2YV9jb3B5KGQscykgKChk KSA9IChzKSkKICMgIGVuZGlmCiAjIGVsc2UJLyogbm90IF9XSU42NCAqLwogIyAgZGVmaW5lIHZh X2NvcHkoZCxzKSAoKGQpID0gKHMpKQpAQCAtNDI5LDcgKzQzMywxMSBAQAogCiAgICBTZWUgbS90 ZW1wbGF0ZS5oIGZvciBkb2N1bWVudGF0aW9uIG9uIHdyaXRpbmcgbS9NQUNISU5FLmggZmlsZXMu ICAqLwogI3VuZGVmIGNvbmZpZ19tYWNoZmlsZQorI2lmZGVmIF9XSU42NAorI2luY2x1ZGUgIm0v YW1keDg2LTY0LmgiCisjZWxzZQogI2luY2x1ZGUgIm0vaW50ZWwzODYuaCIKKyNlbmRpZgogCiAv KiBEZWZpbmUgYHN1YnByb2Nlc3Nlcycgc2hvdWxkIGJlIGRlZmluZWQgaWYgeW91IHdhbnQgdG8K ICAgIGhhdmUgY29kZSBmb3IgYXN5bmNocm9ub3VzIHN1YnByb2Nlc3NlcwoKPT09IG1vZGlmaWVk IGZpbGUgJ250L2NvbmZpZ3VyZS5iYXQnCi0tLSBudC9jb25maWd1cmUuYmF0CTIwMTEtMDUtMDcg MDQ6MDA6MTIgKzAwMDAKKysrIG50L2NvbmZpZ3VyZS5iYXQJMjAxMS0xMS0wOSAxNTo0Mzo0MiAr MDAwMApAQCAtOTYsOCArOTYsOCBAQAogc2V0IHByb2ZpbGU9Tg0KIHNldCBub2N5Z3dpbj1ODQog c2V0IENPTVBJTEVSPQ0KLXNldCB1c2VyY2ZsYWdzPQ0KLXNldCBlc2N1c2VyY2ZsYWdzPQ0KK3Nl dCB1c2VyY2ZsYWdzPS1JLi4vc3JjIC1JLi4vbnQvaW5jIC1JLi4vbGliIC1JYzovc291cmNlL1hF bVRlWC9zb3VyY2UvbGlicy93MzJjb21wYXQgLUljOi9zb3VyY2UvWEVtVGVYL3NvdXJjZS9saWJz L3psaWItMS4yLjUgLUljOi9zb3VyY2UvWEVtVGVYL3NvdXJjZS9saWJzL2xpYnBuZy0xLjUuNCAt SWM6L3NvdXJjZS9YRW1UZVgvc291cmNlL2xpYnMvanBlZy04YiAtSWM6L3NvdXJjZS9YRW1UZVgv c291cmNlL2xpYnMvdGlmZi0zLjkuNS9saWJ0aWZmIC1JYzovc291cmNlL1hFbVRlWC9zb3VyY2Uv bGlicy9naWZsaWItNC4xLjYvbGliIC1JYzovc291cmNlL1hFbVRlWC9zb3VyY2UvbGlicy94cG0t My40ayAtSWM6L3NvdXJjZS9YRW1UZVgvc291cmNlL2xpYnMveHBtLTMuNGsvbGliDQorc2V0IGVz Y3VzZXJjZmxhZ3M9LUkuLi9zcmMgLUkuLi9udC9pbmMgLUkuLi9saWIgLUljOi9zb3VyY2UvWEVt VGVYL3NvdXJjZS9saWJzL3czMmNvbXBhdCAtSWM6L3NvdXJjZS9YRW1UZVgvc291cmNlL2xpYnMv emxpYi0xLjIuNSAtSWM6L3NvdXJjZS9YRW1UZVgvc291cmNlL2xpYnMvbGlicG5nLTEuNS40IC1J Yzovc291cmNlL1hFbVRlWC9zb3VyY2UvbGlicy9qcGVnLThiIC1JYzovc291cmNlL1hFbVRlWC9z b3VyY2UvbGlicy90aWZmLTMuOS41L2xpYnRpZmYgLUljOi9zb3VyY2UvWEVtVGVYL3NvdXJjZS9s aWJzL2dpZmxpYi00LjEuNi9saWIgLUljOi9zb3VyY2UvWEVtVGVYL3NvdXJjZS9saWJzL3hwbS0z LjRrIC1JYzovc291cmNlL1hFbVRlWC9zb3VyY2UvbGlicy94cG0tMy40ay9saWINCiBzZXQgZG9j ZmxhZ3M9DQogc2V0IHVzZXJsZGZsYWdzPQ0KIHNldCBlc2N1c2VybGRmbGFncz0NCkBAIC01MzYs NyArNTM2LDggQEAKIGVjaG8gVGhlIGZhaWxlZCBwcm9ncmFtIHdhczogPj5jb25maWcubG9nDQog dHlwZSBqdW5rLmMgPj5jb25maWcubG9nDQogc2V0IEhBVkVfUE5HPQ0KLWdvdG8gOnBuZ0RvbmUN CityZW0gZ290byA6cG5nRG9uZQ0KK2dvdG8gOmVuZA0KIA0KIDpoYXZlUG5nDQogZWNobyAuLi5Q TkcgaGVhZGVyIGF2YWlsYWJsZSwgYnVpbGRpbmcgd2l0aCBQTkcgc3VwcG9ydC4NCgo9PT0gbW9k aWZpZWQgZmlsZSAnbnQvZW1hY3MucmMnCi0tLSBudC9lbWFjcy5yYwkyMDExLTEwLTMxIDAyOjI1 OjAxICswMDAwCisrKyBudC9lbWFjcy5yYwkyMDExLTExLTEwIDAyOjQ3OjU4ICswMDAwCkBAIC0x LDYgKzEsMTAgQEAKIEVtYWNzIElDT04gICBpY29uc1xlbWFjcy5pY28KIDMyNjQ5IENVUlNPUiBp Y29uc1xoYW5kLmN1cgorI2lmZGVmIFdJTjY0CisxIDI0ICJlbWFjcy14NjQubWFuaWZlc3QiCisj ZWxzZQogMSAyNCAiZW1hY3MubWFuaWZlc3QiCisjZW5kaWYKIAogI2lmbmRlZiBWU19WRVJTSU9O X0lORk8KICNkZWZpbmUgVlNfVkVSU0lPTl9JTkZPIDEKCj09PSBtb2RpZmllZCBmaWxlICdudC9p bmMvaW50dHlwZXMuaCcKLS0tIG50L2luYy9pbnR0eXBlcy5oCTIwMTEtMDUtMDYgMTI6MDk6MDgg KzAwMDAKKysrIG50L2luYy9pbnR0eXBlcy5oCTIwMTEtMTEtMDggMDQ6MzM6NTcgKzAwMDAKQEAg LTI0LDcgKzI0LDEzIEBACiAjaW5jbHVkZV9uZXh0IDxpbnR0eXBlcy5oPgogI2Vsc2UgIC8qICFf X01JTkdXMzJfXyAqLwogI2luY2x1ZGUgInN0ZGludC5oIgorI2lmZGVmIF9XSU42NAogI2RlZmlu ZSBzdHJ0b3VtYXggX3N0cnRvdWk2NAorI2RlZmluZSBzdHJ0b2ltYXggX3N0cnRvaTY0CisjZWxz ZQorI2RlZmluZSBzdHJ0b3VtYXggc3RydG91bAorI2RlZmluZSBzdHJ0b2ltYXggc3RydG9sCisj ZW5kaWYKICNlbmRpZgkvKiAhX19NSU5HVzMyX18gKi8KIAogI2VuZGlmCgo9PT0gbW9kaWZpZWQg ZmlsZSAnbnQvaW5jL3N0ZGludC5oJwotLS0gbnQvaW5jL3N0ZGludC5oCTIwMTEtMTEtMDUgMjI6 MzM6NDQgKzAwMDAKKysrIG50L2luYy9zdGRpbnQuaAkyMDExLTExLTEwIDAxOjM2OjUwICswMDAw CkBAIC0yOSw3ICsyOSw5IEBACiAKICNpZmRlZiBfV0lONjQKIHR5cGVkZWYgX19pbnQ2NCBpbnRw dHJfdDsKLSNkZWZpbmUgVUlOVDY0X01BWCAxODQ0Njc0NDA3MzcwOTU1MTYxNgordHlwZWRlZiB1 bnNpZ25lZCBpbnQgdWludDMyX3Q7Cit0eXBlZGVmIHVuc2lnbmVkIF9faW50NjQgdWludDY0X3Q7 CisjZGVmaW5lIFVJTlQ2NF9NQVggKDE4NDQ2NzQ0MDczNzA5NTUxNjE1aTY0KQogI2RlZmluZSBV SU5UNjRfTUlOIDAKIC8qICJpNjQiIGlzIHRoZSBub24tc3RhbmRhcmQgc3VmZml4IHVzZWQgYnkg TVNWQyBmb3IgNjQtYml0IGNvbnN0YW50cy4gICovCiAjZGVmaW5lIElOVDY0X01BWCA5MjIzMzcy MDM2ODU0Nzc1ODA3aTY0CkBAIC0zOSw2ICs0MSw4IEBACiAjZGVmaW5lIFVJTlRNQVhfTUlOIFVJ TlQ2NF9NSU4KICNkZWZpbmUgSU5UTUFYX01BWCBJTlQ2NF9NQVgKICNkZWZpbmUgSU5UTUFYX01J TiBJTlQ2NF9NSU4KKyNkZWZpbmUgdWludG1heF90IHVuc2lnbmVkIF9faW50NjQKKyNkZWZpbmUg aW50bWF4X3QgX19pbnQ2NAogI2Vsc2UKIHR5cGVkZWYgaW50IGludHB0cl90OwogdHlwZWRlZiB1 bnNpZ25lZCBpbnQgdWludDMyX3Q7CkBAIC01MSwxMCArNTUsMTAgQEAKICNkZWZpbmUgVUlOVE1B WF9NSU4gVUlOVDMyX01JTgogI2RlZmluZSBJTlRNQVhfTUFYIElOVDMyX01BWAogI2RlZmluZSBJ TlRNQVhfTUlOIElOVDMyX01JTgorI2RlZmluZSB1aW50bWF4X3QgdW5zaWduZWQgbG9uZworI2Rl ZmluZSBpbnRtYXhfdCBsb25nCiAjZW5kaWYKIAotI2RlZmluZSB1aW50bWF4X3QgdW5zaWduZWQg X19pbnQ2NAotI2RlZmluZSBpbnRtYXhfdCBfX2ludDY0CiAjZGVmaW5lIFBUUkRJRkZfTUFYIElO VFBUUl9NQVgKIAogI2VuZGlmCS8qICFfX0dOVUNfXyAqLwoKPT09IG1vZGlmaWVkIGZpbGUgJ250 L25tYWtlLmRlZnMnCi0tLSBudC9ubWFrZS5kZWZzCTIwMTEtMTEtMDUgMTE6MzQ6NTYgKzAwMDAK KysrIG50L25tYWtlLmRlZnMJMjAxMS0xMS0wOSAxNjo1MjoxOSArMDAwMApAQCAtODYsNyArODYs MTEgQEAKICEgICAgaWYgIiQoUFJPQ0VTU09SX0FSQ0hJVEVDVFVSRSkiID09ICJQUEMiDQogQVJD SAkJPSBwcGMNCiAhICAgIGVsc2UNCi0hICAgICBlcnJvciBVbmtub3duIGFyY2hpdGVjdHVyZSB0 eXBlICIkKFBST0NFU1NPUl9BUkNISVRFQ1RVUkUpIg0KKyEgICAgIGlmICIkKFBST0NFU1NPUl9B UkNISVRFQ1RVUkUpIiA9PSAiQU1ENjQiDQorQVJDSAkJPSBBTUQ2NA0KKyEgICAgIGVsc2UNCish ICAgICAgZXJyb3IgVW5rbm93biBhcmNoaXRlY3R1cmUgdHlwZSAiJChQUk9DRVNTT1JfQVJDSElU RUNUVVJFKSINCishICAgICBlbmRpZg0KICEgICAgZW5kaWYNCiAhICAgZW5kaWYNCiAhICBlbmRp Zg0KQEAgLTE2NCw3ICsxNjgsMTEgQEAKIA0KICMgc2VlIGNvbW1lbnRzIGluIGFsbG9jYXRlX2hl YXAgaW4gdzMyaGVhcC5jIGJlZm9yZSBjaGFuZ2luZyBhbnkgb2YgdGhlDQogIyAtc3RhY2ssIC1o ZWFwLCBvciAtYmFzZSBzZXR0aW5ncy4NCishaWYgIiQoQVJDSCkiID09ICJBTUQ2NCINCitURU1B Q1NfRVhUUkFfTElOSyA9IC1zdGFjazoweDAwODAwMDAwIC1oZWFwOjB4MDAxMDAwMDAgLWJhc2U6 MHgwMTAwMDAwMCAtcGRiOiQoQkxEKVx0ZW1hY3MucGRiIC1tYWNoaW5lOng2NCAkKFNVQlNZU1RF TV9DT05TT0xFKSAtZW50cnk6X3N0YXJ0IC1tYXA6JChCTEQpXHRlbWFjcy5tYXAgJChFWFRSQV9M SU5LKQ0KKyFlbHNlDQogVEVNQUNTX0VYVFJBX0xJTksgPSAtc3RhY2s6MHgwMDgwMDAwMCAtaGVh cDoweDAwMTAwMDAwIC1iYXNlOjB4MDEwMDAwMDAgLXBkYjokKEJMRClcdGVtYWNzLnBkYiAtbWFj aGluZTokKEFSQ0gpICQoU1VCU1lTVEVNX0NPTlNPTEUpIC1lbnRyeTpfc3RhcnQgLW1hcDokKEJM RClcdGVtYWNzLm1hcCAkKEVYVFJBX0xJTkspDQorIWVuZGlmDQogDQogIWlmZGVmIE5PT1BUDQog T0JKRElSICAgICAgICAgID0gb2JqDQpAQCAtMjM0LDExICsyNDIsMjQgQEAKIEFSQ0hfTERGTEFH Uwk9ICQoU1lTX0xERkxBR1MpDQogDQogIWVsc2UNCishaWYgIiQoQVJDSCkiID09ICJBTUQ2NCIN CisjIFRoZXNlIGZsYWdzIGFyZSBhIGd1ZXNzLi4uaWYgdGhleSBkb24ndCB3b3JrLCBwbGVhc2Ug c2VuZCBtZSBtYWlsLg0KKyFpZmRlZiBOT09QVA0KKyNBUkNIX0NGTEFHUyAgICAgPSAtbm9sb2dv IC1jIC1aZWwgLVcyIC1INjMgLU9kIC1HM2QgLVpwOCAkKERFQlVHX0ZMQUcpDQorQVJDSF9DRkxB R1MgICAgID0gLW5vbG9nbyAtRF9BTUQ2NF89MSAtRFdJTjY0IC1EX1dJTjY0IC1EV0lOMzIgLURf V0lOMzIgLWMgLVpsIC1acDggLVcyIC1PZCAtR2QgJChERUJVR19GTEFHKQ0KKyFlbHNlDQorI0FS Q0hfQ0ZMQUdTICAgICA9IC1ub2xvZ28gLWMgLVplbCAtVzIgLUg2MyAtT3hzYjIgLU95LSAtRzZk RiAtWnA4ICQoREVCVUdfRkxBRykNCitBUkNIX0NGTEFHUyAgICAgPSAtbm9sb2dvIC1EX0FNRDY0 Xz0xIC1EV0lONjQgLURfV0lONjQgLURXSU4zMiAtRF9XSU4zMiAtYyAtWmwgLVpwOCAtVzIgLU9p IC1PdCAtT3ktIC1PYjIgLUdGIC1HeSAtR2QgJChERUJVR19GTEFHKQ0KKyFlbmRpZg0KK0FSQ0hf TERGTEFHUwk9ICQoU1lTX0xERkxBR1MpIC1tYWNoaW5lOng2NA0KKw0KKyFlbHNlDQogIUVSUk9S IFVua25vd24gYXJjaGl0ZWN0dXJlIHR5cGUgIiQoQVJDSCkiLg0KICFlbmRpZg0KICFlbmRpZg0K ICFlbmRpZg0KICFlbmRpZg0KKyFlbmRpZg0KIA0KIExJTktfRkxBR1MJPSAkKEFSQ0hfTERGTEFH UykgJChERUJVR19MSU5LKSAkKFVTRVJfTERGTEFHUykNCiANCgo9PT0gbW9kaWZpZWQgZmlsZSAn c3JjL2xpc3AuaCcKLS0tIHNyYy9saXNwLmgJMjAxMS0xMS0wNyAxNzowNDowMSArMDAwMAorKysg c3JjL2xpc3AuaAkyMDExLTExLTEwIDE3OjI0OjE0ICswMDAwCkBAIC0xNjMsMTQgKzE2MywyMyBA QAogLyogRmlyc3QsIHRyeSBhbmQgZGVmaW5lIERFQ0xfQUxJR04odHlwZSx2YXIpIHdoaWNoIGRl Y2xhcmVzIGEgc3RhdGljCiAgICB2YXJpYWJsZSBWQVIgb2YgdHlwZSBUWVBFIHdpdGggdGhlIGFk ZGVkIHJlcXVpcmVtZW50IHRoYXQgaXQgYmUKICAgIFRZUEVCSVRTLWFsaWduZWQuICAqLworCisj aWZuZGVmIEdDVFlQRUJJVFMKKyNkZWZpbmUgR0NUWVBFQklUUyAzCisjZW5kaWYKKwogI2lmbmRl ZiBOT19ERUNMX0FMSUdOCiAjIGlmbmRlZiBERUNMX0FMSUdOCiAjICBpZiBIQVZFX0FUVFJJQlVU RV9BTElHTkVECiAjICAgZGVmaW5lIERFQ0xfQUxJR04odHlwZSwgdmFyKSBcCiAgICAgIHR5cGUg X19hdHRyaWJ1dGVfXyAoKF9fYWxpZ25lZF9fICgxIDw8IEdDVFlQRUJJVFMpKSkgdmFyCiAjICBl bGlmIGRlZmluZWQoX01TQ19WRVIpCisjICAgZGVmaW5lIEFMSUdOX0dDVFlQRUJJVFMgOAorIyAg IGlmICgxIDw8IEdDVFlQRUJJVFMpICE9IEFMSUdOX0dDVFlQRUJJVFMKKyMgICAgZXJyb3IgQUxJ R05fR0NUWVBFQklUUyBpcyB3cm9uZyEKKyMgICBlbmRpZgogIyAgIGRlZmluZSBERUNMX0FMSUdO KHR5cGUsIHZhcikgXAotICAgICB0eXBlIF9fZGVjbHNwZWMoYWxpZ24oMSA8PCBHQ1RZUEVCSVRT KSkgdmFyCisgICAgIHR5cGUgX19kZWNsc3BlYyhhbGlnbihBTElHTl9HQ1RZUEVCSVRTKSkgdmFy CiAjICBlbHNlCiAgICAgIC8qIFdoYXQgZGlyZWN0aXZlcyBkbyBvdGhlciBjb21waWxlcnMgdXNl PyAgKi8KICMgIGVuZGlmCkBAIC0zMDAsMTAgKzMwOSw2IEBACiAgICAgTGlzcF9Gd2RfS2JvYXJk X09iaiwJLyogRndkIHRvIGEgTGlzcF9PYmplY3QgZmllbGQgb2Yga2JvYXJkcy4gICovCiAgIH07 CiAKLSNpZm5kZWYgR0NUWVBFQklUUwotI2RlZmluZSBHQ1RZUEVCSVRTIDMKLSNlbmRpZgotCiAv KiBUaGVzZSB2YWx1ZXMgYXJlIG92ZXJyaWRkZW4gYnkgdGhlIG0tIGZpbGUgb24gc29tZSBtYWNo aW5lcy4gICovCiAjaWZuZGVmIFZBTEJJVFMKICNkZWZpbmUgVkFMQklUUyAoQklUU19QRVJfRU1B Q1NfSU5UIC0gR0NUWVBFQklUUykKCj09PSBtb2RpZmllZCBmaWxlICdzcmMvbS9hbWR4ODYtNjQu aCcKLS0tIHNyYy9tL2FtZHg4Ni02NC5oCTIwMTEtMDQtMTkgMDA6MzQ6NDIgKzAwMDAKKysrIHNy Yy9tL2FtZHg4Ni02NC5oCTIwMTEtMTEtMDggMTY6MDA6MTEgKzAwMDAKQEAgLTI3LDkgKzI3LDE3 IEBACiAvKiBfX3g4Nl82NCBkZWZpbmVkIGF1dG9tYXRpY2FsbHkuICAqLwogCiAvKiBEZWZpbmUg dGhlIHR5cGUgdG8gdXNlLiAgKi8KKyNpZmRlZiBfV0lONjQKKyNkZWZpbmUgRU1BQ1NfSU5UICAg ICAgICAgICAgICAgX19pbnQ2NAorI2RlZmluZSBwSQkJCSJpNjQiCisjZGVmaW5lIEVNQUNTX1VJ TlQgICAgICAgICAgICAgIHVuc2lnbmVkIF9faW50NjQKKyNkZWZpbmUgVklSVF9BRERSX1ZBUklF UworI2RlZmluZSBEQVRBX1NUQVJUIAlnZXRfZGF0YV9zdGFydCAoKQorI2Vsc2UKICNkZWZpbmUg RU1BQ1NfSU5UICAgICAgICAgICAgICAgbG9uZwogI2RlZmluZSBwSQkJCSJsIgogI2RlZmluZSBF TUFDU19VSU5UICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nCisjZW5kaWYKIAogLyogRGVmaW5l IFhQTlRSIHRvIGF2b2lkIG9yJ2luZyB3aXRoIERBVEFfU0VHX0JJVFMgKi8KICN1bmRlZiBEQVRB X1NFR19CSVRTCgo9PT0gbW9kaWZpZWQgZmlsZSAnc3JjL21ha2VmaWxlLnczMi1pbicKLS0tIHNy Yy9tYWtlZmlsZS53MzItaW4JMjAxMS0xMS0wNSAyMjo1NTowOCArMDAwMAorKysgc3JjL21ha2Vm aWxlLnczMi1pbgkyMDExLTExLTEwIDAyOjE2OjQ5ICswMDAwCkBAIC0xNzcsNyArMTc3LDcgQEAK ICQoVEVNQUNTKTogICAgICAkKFRMSUIwKSAkKFRMSUIxKSAkKFRMSUIyKSAkKFRMQVNUTElCKSAk KFRPQkopICQoVFJFUykgXAogCQkgIC4uL250LyQoQkxEKS9hZGRzZWN0aW9uLmV4ZSAkKEdOVUxJ QikKIAkkKExJTkspICQoTElOS19PVVQpJChURU1BQ1NfVE1QKSAkKEZVTExfTElOS19GTEFHUykg JChUT0JKKSAkKFRSRVMpICQoTElCUykKLQkiJChUSElTRElSKS8uLi9udC8kKEJMRCkvYWRkc2Vj dGlvbiIgIiQoVEVNQUNTX1RNUCkiICIkKFRFTUFDUykiIEVNSEVBUCAyMQorCSIkKFRISVNESVIp Ly4uL250LyQoQkxEKS9hZGRzZWN0aW9uIiAiJChURU1BQ1NfVE1QKSIgIiQoVEVNQUNTKSIgRU1I RUFQIDQyCiAKICMgVGhlc2Ugb21pdCBmaXJzdGZpbGUuJHtPfSwgYnV0IHRoZXJlJ3Mgbm8gZG9j dW1lbnRhdGlvbiBpbiB0aGVyZQogIyBhbnl3YXlzLgoKPT09IG1vZGlmaWVkIGZpbGUgJ3NyYy9z L21zLXczMi5oJwotLS0gc3JjL3MvbXMtdzMyLmgJMjAxMS0xMS0wNSAxNjozMDoxMyArMDAwMAor Kysgc3JjL3MvbXMtdzMyLmgJMjAxMS0xMS0xMCAxNzo0NjowNyArMDAwMApAQCAtMjc1LDExICsy NzUsMTMgQEAKICNkZWZpbmUgcG9wZW4gICAgIF9wb3BlbgogI2RlZmluZSBwY2xvc2UgICAgX3Bj bG9zZQogI2RlZmluZSB1bWFzawkgIF91bWFzawotI2RlZmluZSB1dGltYnVmCSAgX3V0aW1idWYK KyNkZWZpbmUgc25wcmludGYgIF9zbnByaW50ZgogI2RlZmluZSBzdHJkdXAgICAgX3N0cmR1cAor I2RlZmluZSBzdHJ0b2xsICAgX3N0cnRvaTY0CiAjZGVmaW5lIHN0cnVwciAgICBfc3RydXByCiAj ZGVmaW5lIHN0cm5pY21wICBfc3RybmljbXAKICNkZWZpbmUgc3RyaWNtcCAgIF9zdHJpY21wCisv KiAjZGVmaW5lIHR6bmFtZSAgICBfdHpuYW1lICovCiAjZGVmaW5lIHR6c2V0ICAgICBfdHpzZXQK IAogI2lmICFkZWZpbmVkIChfTVNDX1ZFUikgfHwgKF9NU0NfVkVSIDwgMTQwMCkKQEAgLTMzNSw3 ICszMzcsNyBAQAogI2RlZmluZSBfV0lOU09DS19ICiAKIC8qIERlZmluZXMgc2l6ZV90IGFuZCBh bGxvY2EgKCkuICAqLwotI2lmIChkZWZpbmVkKF9NU0NfVkVSKSAmJiBkZWZpbmVkKGVtYWNzKSkg fHwgZGVmaW5lZChVU0VfQ1JUX0RMTCkKKyNpZiAoZGVmaW5lZChfTVNDX1ZFUikgJiYgZGVmaW5l ZChlbWFjcykpCiAjZGVmaW5lIG1hbGxvYyBlX21hbGxvYwogI2RlZmluZSBmcmVlICAgZV9mcmVl CiAjZGVmaW5lIHJlYWxsb2MgZV9yZWFsbG9jCgo9PT0gbW9kaWZpZWQgZmlsZSAnc3JjL3czMi5j JwotLS0gc3JjL3czMi5jCTIwMTEtMTEtMDcgMTY6NDI6MzQgKzAwMDAKKysrIHNyYy93MzIuYwky MDExLTExLTEwIDE3OjQ2OjUwICswMDAwCkBAIC0xNjY1LDEwICsxNjY1LDEwIEBACiAKICAgICAg IGlmICghR2V0TW9kdWxlRmlsZU5hbWUgKE5VTEwsIG1vZG5hbWUsIE1BWF9QQVRIKSkKIAlhYm9y dCAoKTsKKwogICAgICAgaWYgKChwID0gc3RycmNociAobW9kbmFtZSwgJ1xcJykpID09IE5VTEwp CiAJYWJvcnQgKCk7CiAgICAgICAqcCA9IDA7Ci0KICAgICAgIGlmICgocCA9IHN0cnJjaHIgKG1v ZG5hbWUsICdcXCcpKSAmJiB4c3RyY2FzZWNtcCAocCwgIlxcYmluIikgPT0gMCkKIAl7CiAJICBj aGFyIGJ1ZltTRVRfRU5WX0JVRl9TSVpFXTsKQEAgLTE2ODUsNyArMTY4NSw4IEBACiAgICAgICAv KiBGSVhNRTogc2hvdWxkIHVzZSBzdWJzdHJpbmcgb2YgZ2V0X2VtYWNzX2NvbmZpZ3VyYXRpb24g KCkuCiAJIEJ1dCBJIGRvbid0IHRoaW5rIHRoZSBXaW5kb3dzIGJ1aWxkIHN1cHBvcnRzIGFscGhh LCBtaXBzIGV0YwogICAgICAgICAgYW55bW9yZSwgc28gaGF2ZSB0YWtlbiB0aGUgZWFzeSBvcHRp b24gZm9yIG5vdy4gICovCi0gICAgICBlbHNlIGlmIChwICYmIHhzdHJjYXNlY21wIChwLCAiXFxp Mzg2IikgPT0gMCkKKyAgICAgIGVsc2UgaWYgKHAgJiYgKHhzdHJjYXNlY21wIChwLCAiXFxpMzg2 IikgPT0gMAorICAgICAgICAgICAgICAgICAgICAgfHwgeHN0cmNhc2VjbXAgKHAsICJcXEFNRDY0 IikgPT0gMCkpCiAJewogCSAgKnAgPSAwOwogCSAgcCA9IHN0cnJjaHIgKG1vZG5hbWUsICdcXCcp OwoKPT09IG1vZGlmaWVkIGZpbGUgJ3NyYy94ZGlzcC5jJwotLS0gc3JjL3hkaXNwLmMJMjAxMS0x MS0wOCAyMDowNToyNyArMDAwMAorKysgc3JjL3hkaXNwLmMJMjAxMS0xMS0xMCAxNzoyMDowNyAr MDAwMApAQCAtMTA4Niw3ICsxMDg2LDExIEBACiAgICBhcmVhIEFSRUEgb2Ygd2luZG93IFcuICBB UkVBIDwgMCBtZWFucyByZXR1cm4gdGhlIHJpZ2h0IGVkZ2Ugb2YgdGhlCiAgICB3aG9sZSB3aW5k b3csIHRvIHRoZSBsZWZ0IG9mIHRoZSByaWdodCBmcmluZ2Ugb2YgVy4gICovCiAKKyNpZmRlZiBf TVNDX1ZFUgogaW50CisjZWxzZQoraW5saW5lIGludAorI2VuZGlmCiB3aW5kb3dfYm94X3JpZ2h0 X29mZnNldCAoc3RydWN0IHdpbmRvdyAqdywgaW50IGFyZWEpCiB7CiAgIHJldHVybiB3aW5kb3df Ym94X2xlZnRfb2Zmc2V0ICh3LCBhcmVhKSArIHdpbmRvd19ib3hfd2lkdGggKHcsIGFyZWEpOwpA QCAtMTExNiw3ICsxMTIwLDExIEBACiAgICBhcmVhIEFSRUEgb2Ygd2luZG93IFcuICBBUkVBIDwg MCBtZWFucyByZXR1cm4gdGhlIHJpZ2h0IGVkZ2Ugb2YgdGhlCiAgICB3aG9sZSB3aW5kb3csIHRv IHRoZSBsZWZ0IG9mIHRoZSByaWdodCBmcmluZ2Ugb2YgVy4gICovCiAKKyNpZmRlZiBfTVNDX1ZF UgogaW50CisjZWxzZQoraW5saW5lIGludAorI2VuZGlmCiB3aW5kb3dfYm94X3JpZ2h0IChzdHJ1 Y3Qgd2luZG93ICp3LCBpbnQgYXJlYSkKIHsKICAgcmV0dXJuIHdpbmRvd19ib3hfbGVmdCAodywg YXJlYSkgKyB3aW5kb3dfYm94X3dpZHRoICh3LCBhcmVhKTsKCg== --14dae9c097fe22329d04b166cd9c Content-Type: application/octet-stream; name="emacs-x64.manifest" Content-Disposition: attachment; filename="emacs-x64.manifest" Content-Transfer-Encoding: base64 X-Attachment-Id: f_guu6cmlr1 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pgo8 YXNzZW1ibHkgeG1sbnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206YXNtLnYxIiBtYW5pZmVz dFZlcnNpb249IjEuMCI+CiAgPGRlcGVuZGVuY3k+CiAgICA8ZGVwZW5kZW50QXNzZW1ibHk+CiAg ICAgIDxhc3NlbWJseUlkZW50aXR5IHR5cGU9IndpbjMyIiBuYW1lPSJNaWNyb3NvZnQuV2luZG93 cy5Db21tb24tQ29udHJvbHMiCiAgICAgICAgICAgICAgICAgICAgICAgIHZlcnNpb249IjYuMC4w LjAiIHByb2Nlc3NvckFyY2hpdGVjdHVyZT0iQU1ENjQiCiAgICAgICAgICAgICAgICAgICAgICAg IHB1YmxpY0tleVRva2VuPSI2NTk1YjY0MTQ0Y2NmMWRmIgogICAgICAgICAgICAgICAgICAgICAg ICBsYW5ndWFnZT0iKiIvPgogICAgPC9kZXBlbmRlbnRBc3NlbWJseT4KICA8L2RlcGVuZGVuY3k+ CiAgPGFzc2VtYmx5SWRlbnRpdHkgdmVyc2lvbj0iMS4wLjAuMCIgcHJvY2Vzc29yQXJjaGl0ZWN0 dXJlPSJBTUQ2NCIKCQkgICAgbmFtZT0iZW1hY3MiIHR5cGU9IndpbjMyIi8+CiAgPGRlc2NyaXB0 aW9uPkdOVSBFbWFjczwvZGVzY3JpcHRpb24+CiAgPHRydXN0SW5mbyB4bWxucz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTphc20udjMiPgogICAgPHNlY3VyaXR5PgogICAgICA8cmVxdWVzdGVk UHJpdmlsZWdlcz4KICAgICAgICA8cmVxdWVzdGVkRXhlY3V0aW9uTGV2ZWwgbGV2ZWw9ImFzSW52 b2tlciIvPgogICAgICA8L3JlcXVlc3RlZFByaXZpbGVnZXM+CiAgICA8L3NlY3VyaXR5PgogIDwv dHJ1c3RJbmZvPgo8L2Fzc2VtYmx5Pgo= --14dae9c097fe22329d04b166cd9c Content-Type: text/x-chdr; charset=US-ASCII; name="w32compat.h" Content-Disposition: attachment; filename="w32compat.h" Content-Transfer-Encoding: base64 X-Attachment-Id: f_guu6d0sm2 DQojaWZuZGVmIF9XMzJDT01QQVRfSF8NCiNkZWZpbmUgX1czMkNPTVBBVF9IXyAxDQoNCiNpbmNs dWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPGZjbnRsLmg+DQoj aW5jbHVkZSA8aW8uaD4NCiNpbmNsdWRlIDxjb25pby5oPg0KI2luY2x1ZGUgPGRpcmVjdC5oPg0K I2luY2x1ZGUgPG1hbGxvYy5oPg0KI2luY2x1ZGUgPC4uL2luY2x1ZGUvcHJvY2Vzcy5oPg0KI2lu Y2x1ZGUgPHRpbWUuaD4NCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNkZWZpbmUgZGV2X3QgX2Rl dl90DQojZGVmaW5lIGZzdGF0IF9mc3RhdA0KI2RlZmluZSBjaG1vZCBfY2htb2QNCiNpbmNsdWRl IDxzeXMvc3RhdC5oPg0KI2luY2x1ZGUgPC4uL2luY2x1ZGUvc3lzL3RpbWUuaD4NCiNpbmNsdWRl IDxzeXMvdXRpbWUuaD4NCiNpbmNsdWRlIDxzeXMvbG9ja2luZy5oPg0KDQojaW5jbHVkZSA8c2ln bmFsLmg+DQp0eXBlZGVmIHVuc2lnbmVkIGludCBzaWdzZXRfdDsNCg0KdHlwZWRlZiB1bnNpZ25l ZCBpbnQgc3NpemVfdDsNCg0KI2lmbmRlZiBfV0lONjQNCnR5cGVkZWYgdW5zaWduZWQgc2hvcnQg bW9kZV90Ow0KI2VuZGlmDQoNCiNpZiAwDQpzdHJ1Y3QgdGltZXpvbmUNCiAgew0KICAgIGludAl0 el9taW51dGVzd2VzdDsJLyogbWludXRlcyB3ZXN0IG9mIEdyZWVud2ljaCAqLw0KICAgIGludAl0 el9kc3R0aW1lOwkvKiB0eXBlIG9mIGRzdCBjb3JyZWN0aW9uICovDQogIH07DQojZW5kaWYNCg0K dm9pZCBnZXR0aW1lb2ZkYXkgKHN0cnVjdCB0aW1ldmFsICosIHN0cnVjdCB0aW1lem9uZSAqKTsN CnN0cnVjdCB0bSAqZ210aW1lX3IgKHRpbWVfdCBjb25zdCAqIF9fcmVzdHJpY3QsIHN0cnVjdCB0 bSAqIF9fcmVzdHJpY3QpOw0Kc3RydWN0IHRtICpsb2NhbHRpbWVfciAodGltZV90IGNvbnN0ICog X19yZXN0cmljdCwgc3RydWN0IHRtICogX19yZXN0cmljdCk7DQoNCiNpbmNsdWRlIDxzdHJpbmcu aD4NCiNpbmNsdWRlIDxtYnN0cmluZy5oPg0KDQojZGVmaW5lIGlubGluZSBfX2lubGluZQ0KDQoj aWZuZGVmIE9fUkRPTkxZDQojZGVmaW5lIE9fUkRPTkxZIF9PX1JET05MWQ0KI2VuZGlmDQojaWZu ZGVmIE9fV1JPTkxZDQojZGVmaW5lIE9fV1JPTkxZIF9PX1dST05MWQ0KI2VuZGlmDQojaWZuZGVm IE9fUkRXUg0KI2RlZmluZSBPX1JEV1IgX09fUkRXUg0KI2VuZGlmDQojaWZuZGVmIE9fQVBQRU5E DQojZGVmaW5lIE9fQVBQRU5EIF9PX0FQUEVORA0KI2VuZGlmDQojaWZuZGVmIE9fQ1JFQVQNCiNk ZWZpbmUgT19DUkVBVCBfT19DUkVBVA0KI2VuZGlmDQojaWZuZGVmIE9fVFJVTkMNCiNkZWZpbmUg T19UUlVOQyBfT19UUlVOQw0KI2VuZGlmDQojaWZuZGVmIE9fRVhDTA0KI2RlZmluZSBPX0VYQ0wg X09fRVhDTA0KI2VuZGlmDQojaWZuZGVmIE9fVEVYVA0KI2RlZmluZSBPX1RFWFQgX09fVEVYVA0K I2VuZGlmDQojaWZuZGVmIE9fQklOQVJZDQojZGVmaW5lIE9fQklOQVJZIF9PX0JJTkFSWQ0KI2Vu ZGlmDQojaWZuZGVmIE9fUkFXDQojZGVmaW5lIE9fUkFXICAgICAgICAgICBfT19CSU5BUlkNCiNl bmRpZg0KI2lmbmRlZiBPX1RFTVBPUkFSWQ0KI2RlZmluZSBPX1RFTVBPUkFSWSAgICAgX09fVEVN UE9SQVJZDQojZW5kaWYNCiNpZm5kZWYgT19OT0lOSEVSSVQNCiNkZWZpbmUgT19OT0lOSEVSSVQg ICAgIF9PX05PSU5IRVJJVA0KI2VuZGlmDQojaWZuZGVmIE9fU0VRVUVOVElBTA0KI2RlZmluZSBP X1NFUVVFTlRJQUwgICAgX09fU0VRVUVOVElBTA0KI2VuZGlmDQojaWZuZGVmIE9fUkFORE9NDQoj ZGVmaW5lIE9fUkFORE9NICAgICAgICBfT19SQU5ET00NCiNlbmRpZg0KDQojZGVmaW5lIGFsbG9j YSBfYWxsb2NhDQojZGVmaW5lIHN0cmljbXAgX3N0cmljbXANCg0KI2RlZmluZSBhY2Nlc3MgX2Fj Y2Vzcw0KI2RlZmluZSBjaG1vZCBfY2htb2QNCiNkZWZpbmUgY2hzaXplIF9jaHNpemUNCiNkZWZp bmUgY2xvc2UgX2Nsb3NlDQojZGVmaW5lIGNyZWF0IF9jcmVhdA0KI2RlZmluZSBkdXAgX2R1cA0K I2RlZmluZSBkdXAyIF9kdXAyDQojaWYgMA0KLyogVGhpcyBvbmUgY29uZmxpY3RzIHdpdGggdGV4 ay93ZWIyL2xpYi9lb2Zlb2xuLmMgKi8NCiNkZWZpbmUgZW9mIF9lb2YNCiNlbmRpZg0KI2RlZmlu ZSBmaWxlbGVuZ3RoIF9maWxlbGVuZ3RoDQojZGVmaW5lIGlzYXR0eSBfaXNhdHR5DQojZGVmaW5l IGxvY2tpbmcgX2xvY2tpbmcNCiNkZWZpbmUgbHNlZWsgX2xzZWVrDQojZGVmaW5lIG1rdGVtcCBf bWt0ZW1wDQojZGVmaW5lIG9wZW4gX29wZW4NCiNkZWZpbmUgcmVhZCBfcmVhZA0KI2RlZmluZSBz ZXRtb2RlIF9zZXRtb2RlDQojZGVmaW5lIHNvcGVuIF9zb3Blbg0KI2RlZmluZSB0ZWxsIF90ZWxs DQojZGVmaW5lIHVtYXNrIF91bWFzaw0KI2RlZmluZSB1bmxpbmsgX3VubGluaw0KI2RlZmluZSB3 cml0ZSBfd3JpdGUNCg0KI2RlZmluZSBjZ2V0cyBfY2dldHMNCiNkZWZpbmUgY3ByaW50ZiBfY3By aW50Zg0KI2RlZmluZSBjcHV0cyBfY3B1dHMNCiNkZWZpbmUgY3NjYW5mIF9jc2NhbmYNCiNkZWZp bmUgaW5wIF9pbnANCiNkZWZpbmUgaW5wdyBfaW5wdw0KI2RlZmluZSBnZXRjaCBfZ2V0Y2gNCiNk ZWZpbmUgZ2V0Y2hlIF9nZXRjaGUNCiNkZWZpbmUga2JoaXQgX2tiaGl0DQojZGVmaW5lIG91dHAg X291dHANCiNkZWZpbmUgb3V0cHcgX291dHB3DQojZGVmaW5lIHB1dGNoIF9wdXRjaA0KI2RlZmlu ZSB1bmdldGNoIF91bmdldGNoDQoNCiNkZWZpbmUgY2hkaXIgX2NoZGlyDQojZGVmaW5lIGdldGN3 ZCBfZ2V0Y3dkDQojZGVmaW5lIG1rZGlyIF9ta2Rpcg0KI2RlZmluZSBybWRpciBfcm1kaXINCg0K I2RlZmluZSBDTEtfVENLICBDTE9DS1NfUEVSX1NFQw0KDQojaWYgX01TQ19WRVIgPD0gMTMxMA0K I2RlZmluZSB0aW1lem9uZSBfdGltZXpvbmUNCiNlbmRpZg0KI2RlZmluZSBkYXlsaWdodCBfZGF5 bGlnaHQNCiNkZWZpbmUgdHpuYW1lIF90em5hbWUNCiNkZWZpbmUgdHpzZXQgX3R6c2V0DQoNCiNk ZWZpbmUgUF9XQUlUICAgICAgICAgIF9QX1dBSVQNCiNkZWZpbmUgUF9OT1dBSVQgICAgICAgIF9Q X05PV0FJVA0KI2RlZmluZSBQX09WRVJMQVkgICAgICAgX1BfT1ZFUkxBWQ0KI2RlZmluZSBPTERf UF9PVkVSTEFZICAgX09MRF9QX09WRVJMQVkNCiNkZWZpbmUgUF9OT1dBSVRPICAgICAgIF9QX05P V0FJVE8NCiNkZWZpbmUgUF9ERVRBQ0ggICAgICAgIF9QX0RFVEFDSA0KI2RlZmluZSBXQUlUX0NI SUxEICAgICAgX1dBSVRfQ0hJTEQNCiNkZWZpbmUgV0FJVF9HUkFORENISUxEIF9XQUlUX0dSQU5E Q0hJTEQNCg0KI2RlZmluZSBjd2FpdCBfY3dhaXQNCiNkZWZpbmUgZXhlY2wgX2V4ZWNsDQojZGVm aW5lIGV4ZWNsZSBfZXhlY2xlDQojZGVmaW5lIGV4ZWNscCBfZXhlY2xwDQojZGVmaW5lIGV4ZWNs cGUgX2V4ZWNscGUNCiNkZWZpbmUgZXhlY3YgX2V4ZWN2DQojZGVmaW5lIGV4ZWN2ZSBfZXhlY3Zl DQojZGVmaW5lIGV4ZWN2cCBfZXhlY3ZwDQojZGVmaW5lIGV4ZWN2cGUgX2V4ZWN2cGUNCiNkZWZp bmUgc3Bhd25sIF9zcGF3bmwNCiNkZWZpbmUgc3Bhd25sZSBfc3Bhd25sZQ0KI2RlZmluZSBzcGF3 bmxwIF9zcGF3bmxwDQojZGVmaW5lIHNwYXdubHBlIF9zcGF3bmxwZQ0KI2RlZmluZSBzcGF3bnYg X3NwYXdudg0KI2RlZmluZSBzcGF3bnZlIF9zcGF3bnZlDQojZGVmaW5lIHNwYXdudnAgX3NwYXdu dnANCiNkZWZpbmUgc3Bhd252cGUgX3NwYXdudnBlDQoNCiNkZWZpbmUgZ2V0cGlkIF9nZXRwaWQN Cg0KI2RlZmluZSBQX3RtcGRpciAgX1BfdG1wZGlyDQojZGVmaW5lIFNZU19PUEVOICBfU1lTX09Q RU4NCg0KI2RlZmluZSBmY2xvc2VhbGwgX2ZjbG9zZWFsbA0KI2RlZmluZSBmZG9wZW4gX2Zkb3Bl bg0KI2RlZmluZSBmZ2V0Y2hhciBfZmdldGNoYXINCiNkZWZpbmUgZmlsZW5vIF9maWxlbm8NCiNk ZWZpbmUgZmx1c2hhbGwgX2ZsdXNoYWxsDQojZGVmaW5lIGZwdXRjaGFyIF9mcHV0Y2hhcg0KI2Rl ZmluZSBnZXR3IF9nZXR3DQojZGVmaW5lIHB1dHcgX3B1dHcNCiNkZWZpbmUgcm10bXAgX3JtdG1w DQojZGVmaW5lIHRlbXBuYW0gX3RlbXBuYW0NCiNkZWZpbmUgdW5saW5rIF91bmxpbmsNCg0KI2Rl ZmluZSBzeXNfZXJybGlzdCBfc3lzX2Vycmxpc3QNCiNkZWZpbmUgc3lzX25lcnIgICAgX3N5c19u ZXJyDQojZGVmaW5lIGVudmlyb24gICAgIF9lbnZpcm9uDQoNCiNkZWZpbmUgb25leGl0X3QgX29u ZXhpdF90DQoNCiNkZWZpbmUgZWN2dCBfZWN2dA0KI2RlZmluZSBmY3Z0IF9mY3Z0DQojZGVmaW5l IGdjdnQgX2djdnQNCiNkZWZpbmUgaXRvYSBfaXRvYQ0KI2RlZmluZSBsdG9hIF9sdG9hDQojZGVm aW5lIG9uZXhpdCBfb25leGl0DQojZGVmaW5lIHB1dGVudiBfcHV0ZW52DQojZGVmaW5lIHN3YWIg X3N3YWINCiNkZWZpbmUgdWx0b2EgX3VsdG9hDQoNCiNpZm5kZWYgU19JRk1UDQojZGVmaW5lIFNf SUZNVCBfU19JRk1UDQojZW5kaWYNCiNpZm5kZWYgU19JRkRJUg0KI2RlZmluZSBTX0lGRElSIF9T X0lGRElSDQojZW5kaWYNCiNpZm5kZWYgU19JRkNIUg0KI2RlZmluZSBTX0lGQ0hSIF9TX0lGQ0hS DQojZW5kaWYNCiNpZm5kZWYgU19JRklGTw0KI2RlZmluZSBTX0lGSUZPIF9TX0lGSUZPDQojZW5k aWYNCiNpZm5kZWYgU19JRlJFRw0KI2RlZmluZSBTX0lGUkVHIF9TX0lGUkVHDQojZW5kaWYNCiNp Zm5kZWYgU19JUkVBRA0KI2RlZmluZSBTX0lSRUFEIF9TX0lSRUFEDQojZW5kaWYNCiNpZm5kZWYg U19JV1JJVEUNCiNkZWZpbmUgU19JV1JJVEUgX1NfSVdSSVRFDQojZW5kaWYNCiNpZm5kZWYgU19J RVhFQw0KI2RlZmluZSBTX0lFWEVDICBfU19JRVhFQw0KI2VuZGlmDQojaWZuZGVmIFNfSVhVU1IN CiNkZWZpbmUgU19JWFVTUiBfU19JRVhFQw0KI2VuZGlmDQojaWZuZGVmIFNfSVhHUlANCiNkZWZp bmUgU19JWEdSUCBfU19JRVhFQw0KI2VuZGlmDQojaWZuZGVmIFNfSVhPVEgNCiNkZWZpbmUgU19J WE9USCBfU19JRVhFQw0KI2VuZGlmDQojaWZuZGVmIFNfSVJVU1INCiNkZWZpbmUgU19JUlVTUiBf U19JUkVBRA0KI2VuZGlmDQojaWZuZGVmIFNfSVJHUlANCiNkZWZpbmUgU19JUkdSUCBfU19JUkVB RA0KI2VuZGlmDQojaWZuZGVmIFNfSVJPVEgNCiNkZWZpbmUgU19JUk9USCBfU19JUkVBRA0KI2Vu ZGlmDQojaWZuZGVmIFNfSVdVU1INCiNkZWZpbmUgU19JV1VTUiBfU19JV1JJVEUNCiNlbmRpZg0K I2lmbmRlZiBTX0lXR1JQDQojZGVmaW5lIFNfSVdHUlAgX1NfSVdSSVRFDQojZW5kaWYNCiNpZm5k ZWYgU19JV09USA0KI2RlZmluZSBTX0lXT1RIIF9TX0lXUklURQ0KI2VuZGlmDQoNCiNpZiAwDQoj ZGVmaW5lIHN0YXQgX3N0YXQ2NGkzMg0KI2VuZGlmDQoNCnR5cGVkZWYgbG9uZyBvZmZfdDsNCg0K LyogZnJvbSBzdHJpbmcuaCAqLw0KI2RlZmluZSBtZW1jY3B5IF9tZW1jY3B5DQojZGVmaW5lIG1l bWljbXAgX21lbWljbXANCiNkZWZpbmUgc3RyY21waSBfc3RyY21waQ0KI2RlZmluZSBzdHJpY21w IF9zdHJpY21wDQojZGVmaW5lIHN0cmR1cCBfc3RyZHVwDQojZGVmaW5lIHN0cmx3ciBfc3RybHdy DQojZGVmaW5lIHN0cm5pY21wIF9zdHJuaWNtcA0KI2RlZmluZSBzdHJuc2V0IF9zdHJuc2V0DQoj ZGVmaW5lIHN0cnJldiBfc3RycmV2DQojZGVmaW5lIHN0cnNldCBfc3Ryc2V0DQojZGVmaW5lIHN0 cnVwciBfc3RydXByDQojZGVmaW5lIHdjc2R1cCBfd2NzZHVwDQoNCiNkZWZpbmUgaXNhc2NpaSBf X2lzYXNjaWkNCiNkZWZpbmUgdG9hc2NpaSBfX3RvYXNjaWkNCiNkZWZpbmUgaXNjc3ltZiBfX2lz Y3N5bWYNCiNkZWZpbmUgaXNjc3ltICBfX2lzY3N5bQ0KDQojZGVmaW5lIHRpbWViIF9fdGltZWIz Mg0KDQojZGVmaW5lIGZ0aW1lIF9mdGltZQ0KDQojZGVmaW5lIHV0aW1idWYgX3V0aW1idWYNCiNk ZWZpbmUgdXRpbWUgX3V0aW1lDQoNCiNkZWZpbmUgbG9ja2luZyBfbG9ja2luZw0KI2RlZmluZSBM S19MT0NLIF9MS19MT0NLDQojZGVmaW5lIExLX05CTENLIF9MS19OQkxDSw0KI2RlZmluZSBMS19O QlJMQ0sgX0xLX05CUkxDSw0KI2RlZmluZSBMS19STENLIF9MS19STENLDQojZGVmaW5lIExLX1VO TENLIF9MS19VTkxDSw0KDQojZW5kaWYNCg== --14dae9c097fe22329d04b166cd9c-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2011 20:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132095697113014 (code B ref 9960); Thu, 10 Nov 2011 20:30:02 +0000 Received: (at 9960) by debbugs.gnu.org; 10 Nov 2011 20:29:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObFb-0003Nr-N4 for submit@debbugs.gnu.org; Thu, 10 Nov 2011 15:29:31 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObFa-0003Nf-32 for 9960@debbugs.gnu.org; Thu, 10 Nov 2011 15:29:30 -0500 Received: by laah2 with SMTP id h2so31164laa.3 for <9960@debbugs.gnu.org>; Thu, 10 Nov 2011 12:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u3IBdtJwr7G9m0p3aJTzlikqRU18HWYvgoRaQUvYOT0=; b=k2zUmFsdrGjwF0pvMmZEQnwQQaglCo/jLQy2IVIN1Fq2itBjOT318Oqs8MR/ASwnHC k9x4qTcEhkk623BJyHa8VWd4Rx33ia56SCg53ShmK0F0xAvyRmggsjLZSs766K4k2o5X vmtNlLBy6Whvc+5OfimL3vxe9SYyOwl9kpqsQ= Received: by 10.152.132.39 with SMTP id or7mr5380768lab.14.1320956951547; Thu, 10 Nov 2011 12:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.38.198 with HTTP; Thu, 10 Nov 2011 12:28:49 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Lennart Borgman Date: Thu, 10 Nov 2011 21:28:49 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau 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). From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2011 20:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132095702713162 (code B ref 9960); Thu, 10 Nov 2011 20:31:01 +0000 Received: (at 9960) by debbugs.gnu.org; 10 Nov 2011 20:30:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObGV-0003QE-1T for submit@debbugs.gnu.org; Thu, 10 Nov 2011 15:30:27 -0500 Received: from mail-pz0-f50.google.com ([209.85.210.50]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObGT-0003Q3-BH for 9960@debbugs.gnu.org; Thu, 10 Nov 2011 15:30:25 -0500 Received: by pzk4 with SMTP id 4so3276864pzk.9 for <9960@debbugs.gnu.org>; Thu, 10 Nov 2011 12:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bmCeCEvj6AfRe72/H4hqB6qAhCf7p2xMbd5U7RX5R+k=; b=BpwCsm+XWqNGh3zJ0NnvJll4bgRn3J7feV75PGg56Smo7VVMvTfEKHo18QPW6jD0Ft wnSgJsOrRuzQWI7WtN4+kX4YRKhr2o7UU0eXQ7ND0AHC5EQdnxiVxh62vqJTI8u5A5mH GOxX74ERsSOIaZapeW/OekjHlwr8lx6arzbhU= Received: by 10.68.11.233 with SMTP id t9mr17168628pbb.121.1320957007089; Thu, 10 Nov 2011 12:30:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Thu, 10 Nov 2011 12:29:26 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Juanma Barranquero Date: Thu, 10 Nov 2011 21:29:26 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau wrote: > Is there any interest in having a 64bits windows emacs ? Yes. =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2011 20:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lennart Borgman Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132095717113387 (code B ref 9960); Thu, 10 Nov 2011 20:33:02 +0000 Received: (at 9960) by debbugs.gnu.org; 10 Nov 2011 20:32:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObIo-0003Tr-IV for submit@debbugs.gnu.org; Thu, 10 Nov 2011 15:32:51 -0500 Received: from mail-yx0-f172.google.com ([209.85.213.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RObIm-0003Te-Rq for 9960@debbugs.gnu.org; Thu, 10 Nov 2011 15:32:49 -0500 Received: by yenq4 with SMTP id q4so4415yen.3 for <9960@debbugs.gnu.org>; Thu, 10 Nov 2011 12:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rPp4rKS+AlasToC5s0+8hQum96/U3BlfGVOSFZfXgag=; b=I8cRO7vLYvR9TXe9BRwTfurjEbL3QBGGjV3xDyCBWXw96q7VYXiPFIDHV5nzwdykbD CQSpjgdS5L3BjOyZ5ccL277fIWl2hzflzj3FvPZpDiCLSHqDXH9Z89za1Z4FLoc8lfNk LWrbIVV9W9C0Kus3urGc7pdmTmeYRcgV9RqVU= Received: by 10.68.25.198 with SMTP id e6mr17456683pbg.19.1320957150126; Thu, 10 Nov 2011 12:32:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Thu, 10 Nov 2011 12:31:49 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Juanma Barranquero Date: Thu, 10 Nov 2011 21:31:49 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Nov 10, 2011 at 21:28, Lennart Borgman 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? =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132100453920780 (code B ref 9960); Fri, 11 Nov 2011 09:43:02 +0000 Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 09:42:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROnco-0005P6-SG for submit@debbugs.gnu.org; Fri, 11 Nov 2011 04:42:19 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROncm-0005Ol-8x for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 04:42:17 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUH00400PJQ7H00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 11:41:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.231.130]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUH003COPLSI3B0@a-mtaout20.012.net.il>; Fri, 11 Nov 2011 11:41:53 +0200 (IST) Date: Fri, 11 Nov 2011 11:39:56 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8339dvgfpv.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Fabrice Popineau > Date: Thu, 10 Nov 2011 20:56:11 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > Sure. feel free to adapt on the basis of the attached patch. > Status is : > - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able to > boostrap itself. Great news, thanks. > Is there any interest in having a 64bits windows emacs ? Yes, though if the changes are significant, they will probably not make it into Emacs 24.1. Plus, I think you will need to sign legal papers to contribute more than what you already have. (I can currently find on file your assignment only to Gnus.) > I have added two other files : a 64bits manifest for emacs.exe and a > w32compat.h header file that is needed to compile the above mentioned > libraries. In my case, this w32compat.h is included while compiling image.c > for example. Is this for a 64-bit build, or is this needed for a 32-bit build as well? If for a 32-bit built, then what exactly are the problems with image.c that requires w32compat.h? > +#ifndef _MSC_VER > extern char **environ; > +#endif Which MSVC header has the necessary declaration, and what is that declaration? > --- lib/strftime.c 2011-03-31 04:24:03 +0000 > +++ lib/strftime.c 2011-11-10 17:39:37 +0000 > @@ -36,9 +36,14 @@ > #include > #include > > +#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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132103974916377 (code B ref 9960); Fri, 11 Nov 2011 19:30:02 +0000 Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 19:29:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROwmj-0004G5-3Z for submit@debbugs.gnu.org; Fri, 11 Nov 2011 14:29:09 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROwmf-0004FQ-Ro for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 14:29:07 -0500 Received: by bkbzv15 with SMTP id zv15so3422116bkb.3 for <9960@debbugs.gnu.org>; Fri, 11 Nov 2011 11:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QnTVMIvDyzqgllCoBAmG7K+Ri3aGSUKY0pwKEAoWKFQ=; b=JczgJqDznQZl66UirBPAR3aoay50/7HAI9c14c5tmdgSJqxJQx97JAxP8WiL3qh5Yd 6kHCpCb4P/RPTWODsXaRvH3iySm2aa9WRsiQdjj8KygglNB3fukV/rWkpBJCQRkj8/HP QFdrSnvewxOjyXXHZUGijCqFtUMi31XfkUKew= Received: by 10.204.29.8 with SMTP id o8mr9299379bkc.48.1321039722137; Fri, 11 Nov 2011 11:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Fri, 11 Nov 2011 11:28:21 -0800 (PST) In-Reply-To: <8339dvgfpv.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> From: Fabrice Popineau Date: Fri, 11 Nov 2011 20:28:21 +0100 X-Google-Sender-Auth: -E1pYoYHG0ngIDYHCzn62BYnuV0 Message-ID: Content-Type: multipart/alternative; boundary=00032556075e5f4bbd04b17a8741 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --00032556075e5f4bbd04b17a8741 Content-Type: text/plain; charset=ISO-8859-1 > > 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 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 > > #include > > > > +#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 --00032556075e5f4bbd04b17a8741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, though if t= he changes are significant, they will probably not
make it into Emacs 24.1. =A0Plus, I think you will need to sign legal
papers to contribute more than what you already have. =A0(I can
currently find on file your assignment only to Gnus.)


Ok, I'll d= o it if needed. Albeit it is almost only a matter of configuring the right = defines.
=A0
> 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<= br> > libraries. In my case, this w32compat.h is included while compiling im= age.c
> for example.

Is this for a 64-bit build, or is this needed for a 32-bit build as well? =A0If 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 p= ng.h (for example) and png.h
may compile out of the box ... or no= t. In my case, I always try to compile=A0
all=A0the libraries wit= h the same set of defines and options. So I included this
file for completeness.

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

=
=A0
> +#ifndef _MSC_VER
> =A0 =A0 =A0 =A0extern char **environ;
> +#endif

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

#include <stdlib.h><= /div>
is enough.

Extract :

=
#if !defined(_M_CEE_PURE)
#ifdef =A0_POSIX_
extern char ** environ; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer to environment t= able */
#else
_CRTIMP extern char ** _environ; =A0 =A0/= * pointer to environment table */
_CRTIMP extern wchar_t ** _wenv= iron; =A0 =A0/* pointer to wide environment table */
#endif =A0/* _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** __cdec= l __p__wpgmptr(void);

#define _environ =A0 (*__p__= environ())
#define _wenviron =A0(*__p__wenviron())
#def= ine _pgmptr =A0 =A0(*__p__pgmptr())
#define _wpgmptr =A0 (*__p__wpgmptr())

#endif= /* !defined(_M_CEE_PURE) */


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

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

Ok, I removed the restriction on MSVC version b= elow 1400 and that is compiling.
=A0
> --- lisp/bindings.el =A02011-10-08 16:37:46 +0000
> +++ lisp/bindings.el =A02011-11-10 17:49:35 +0000
> @@ -824,13 +824,13 @@
> =A0;; Define control-digits.
> =A0(let ((i ?0))
> =A0 =A0(while (<=3D i ?9)
> - =A0 =A0(define-key global-map (read (format "[?\\C-%c]" i)= ) 'digit-argument)
> +; =A0 =A0(define-key global-map (read (format "[?\\C-%c]" i= )) 'digit-argument)
> =A0 =A0 =A0(setq i (1+ i))))
> =A0(define-key global-map [?\C--] 'negative-argument)
> =A0;; Define control-meta-digits.
> =A0(let ((i ?0))
> =A0 =A0(while (<=3D i ?9)
> - =A0 =A0(define-key esc-map (read (format "[?\\C-%c]" i)) &= #39;digit-argument)
> +; =A0 =A0(define-key esc-map (read (format "[?\\C-%c]" i)) = 'digit-argument)
> =A0 =A0 =A0(setq i (1+ i))))
> =A0(define-key global-map [?\C-\M--] 'negative-argument)

Why is this part needed?

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

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

It is faili= ng only while bootstrapping, not during =A0the regular build.


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

Is such a large heap really needed for a 32-bit MSVC build? =A0Or 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 mom= ent.

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=A0
the sdk). That may make addsection usele= ss, and wrt to a 64bits build,=A0
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.

=A0
> -#if (defined(_MSC_VER) && defined(emacs)) || defined(USE_CRT_= DLL)
> +#if (defined(_MSC_VER) && defined(emacs))
> =A0#define malloc e_malloc
> =A0#define free =A0 e_free
> =A0#define realloc e_realloc

What was the problem that required this change?

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

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
--00032556075e5f4bbd04b17a8741-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 19:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132104135321643 (code B ref 9960); Fri, 11 Nov 2011 19:56:01 +0000 Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 19:55:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROxCb-0005d2-Aw for submit@debbugs.gnu.org; Fri, 11 Nov 2011 14:55:53 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROxCZ-0005co-1Y for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 14:55:52 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUI00A00GNK9M00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 21:55:21 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUI005IZI08AO62@a-mtaout20.012.net.il>; Fri, 11 Nov 2011 21:55:21 +0200 (IST) Date: Fri, 11 Nov 2011 21:53:24 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83pqgyfnbf.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Fri, 11 Nov 2011 20:28:21 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > +++ lisp/bindings.el 2011-11-10 17:49:35 +0000 > > > @@ -824,13 +824,13 @@ > > > ;; Define control-digits. > > > (let ((i ?0)) > > > (while (<= i ?9) > > > - (define-key global-map (read (format "[?\\C-%c]" i)) > > 'digit-argument) > > > +; (define-key global-map (read (format "[?\\C-%c]" i)) > > 'digit-argument) > > > (setq i (1+ i)))) > > > (define-key global-map [?\C--] 'negative-argument) > > > ;; Define control-meta-digits. > > > (let ((i ?0)) > > > (while (<= i ?9) > > > - (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument) > > > +; (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument) > > > (setq i (1+ i)))) > > > (define-key global-map [?\C-\M--] 'negative-argument) > > > > Why is this part needed? > > > > I would like to know. I get an error when bootstrapping at these lines : > invalid read syntax. I'll have a look. > Also, it seems that it is possible to declare segments using #pragma > and that they can even be resized using the editbin tool (available with > the sdk). That may make addsection useless, and wrt to a 64bits build, > I would be more confident in using the sdk tools if possible. > > I'll try to remove the use of addsection if possible. Well, if someone has > a good reason for which it is not possible, let me know. Most people build Emacs using MinGW, where editbin is not available. But we could tweak gmake.defs and nmake.defs such that MSVC builds do use editbin. > Being able to link against libc or msvcrt is confusing. > Wouldn't it be better if only MSVCRT was supported ? > Does the build work with the static libc ? Sorry, I don't know enough about the various libraries provided by MS to answer that. In general, we must support a build against libraries that are part of the OS, we cannot rely on users having the SDK or the Studio installation. So linking against libraries that are only distributed with VS must be an option. Even using vcredist packages as a prerequisite would be a nuisance. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 21:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132104860232071 (code B ref 9960); Fri, 11 Nov 2011 21:57:01 +0000 Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 21:56:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROz5V-0008LD-Ld for submit@debbugs.gnu.org; Fri, 11 Nov 2011 16:56:42 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROz5T-0008L0-CI for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 16:56:40 -0500 Received: by bkbzv15 with SMTP id zv15so3518087bkb.3 for <9960@debbugs.gnu.org>; Fri, 11 Nov 2011 13:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fIVrTah7VwTfOtb/r9byf26Scwic4j9LUvepsKHlcCM=; b=siaPbqr7PS5MOD63imnjeKWJ5BADImyXEGHRTJz0A75DHrbV4wUY0d0gcwPZ4nq/2G HqCe6OnHnX1xPHlPDyOH/E3wjqy5J3v20ckay86+YW6Cd99/DOOnosVrAL85oE1Ba7Jm yjRBKD37B2t76pGlDa0sRa27ebBuhbkEkrSTo= Received: by 10.204.29.8 with SMTP id o8mr9656639bkc.48.1321048575124; Fri, 11 Nov 2011 13:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Fri, 11 Nov 2011 13:55:54 -0800 (PST) In-Reply-To: <83pqgyfnbf.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> From: Fabrice Popineau Date: Fri, 11 Nov 2011 22:55:54 +0100 X-Google-Sender-Auth: sbiVkmWAffBMSO5QcWuWW26-fxc Message-ID: Content-Type: multipart/alternative; boundary=00032556075e0d25d404b17c97f7 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --00032556075e0d25d404b17c97f7 Content-Type: text/plain; charset=ISO-8859-1 > > > 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 --00032556075e0d25d404b17c97f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I'l= l 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.<= br>
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 32bit= s executable.
Hence the reason for the 64bits manifest. So removi= ng addsection is not a priority
at all.
=A0
> 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 b= y MS
to answer that. =A0In 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. =A0So linking against libraries that are only
distributed with VS must be an option. =A0Even 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 :

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

+#ifndef _MSC_VER
+
=A0int
=A0vfprintf (HANDLE hnd, const char * msg, va_list args)
=A0{
@@ -81,6 +83,7 @@

=A0 =A0return rc;
=
=A0}
+#endif /* _MSC_VER */

=A0void
=A0f= ail (const char * msg, ...)

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

--
Fabrice
--00032556075e0d25d404b17c97f7-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132110603321017 (code B ref 9960); Sat, 12 Nov 2011 13:54:02 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 13:53:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPE1p-0005Sv-0x for submit@debbugs.gnu.org; Sat, 12 Nov 2011 08:53:53 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPE1m-0005Si-O2 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 08:53:52 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUJ00J00VCY1M00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 15:52:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUJ00HP3VVJQMS0@a-mtaout20.012.net.il>; Sat, 12 Nov 2011 15:52:32 +0200 (IST) Date: Sat, 12 Nov 2011 15:50:35 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83hb29fo0k.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Fri, 11 Nov 2011 22:55:54 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > > Being able to link against libc or msvcrt is confusing. > > > Wouldn't it be better if only MSVCRT was supported ? > > > Does the build work with the static libc ? > > > > Sorry, I don't know enough about the various libraries provided by MS > > to answer that. In general, we must support a build against libraries > > that are part of the OS, we cannot rely on users having the SDK or the > > Studio installation. So linking against libraries that are only > > distributed with VS must be an option. Even using vcredist packages > > as a prerequisite would be a nuisance. > > > > Even better point. MSVCRT.dll is provided with the OS and some parts > of it are linked against this dll. However, Visual Studio provides > msvcrt80.dll, msvcrt90.dll, msvcrt100.dll (one for each new release > of VS) and they need to be redistributed with the program. It makes > sense if you are building an installer (it is even easy). > > So, I have rebuilt emacs with the static libc. It is working too, > except for nt/cmdproxy that required : > > === modified file 'nt/cmdproxy.c' > --- nt/cmdproxy.c 2011-04-27 04:19:15 +0000 > +++ nt/cmdproxy.c 2011-11-11 20:41:37 +0000 > @@ -46,6 +46,8 @@ > #define stdout GetStdHandle (STD_OUTPUT_HANDLE) > #define stderr GetStdHandle (STD_ERROR_HANDLE) > > +#ifndef _MSC_VER > + > int > vfprintf (HANDLE hnd, const char * msg, va_list args) > { > @@ -81,6 +83,7 @@ > > return rc; > } > +#endif /* _MSC_VER */ > > void > fail (const char * msg, ...) > > This patch is ok for both the static libc and the dynamic one. > Without it, link complains that printf is redefined in the case of > the static libc. By the way, I don't know how the MingW libraries > are organized, but defining printf and co to spare some functions > when linking ... it doesn't work with cl and libc/msvcrt because > other libc functions are used too : strncpy, strdup etc. So it is > not possible to avoid linking against libc (?). You will have to bear with me, as I cannot easily grok what you are trying to explain. E.g., what is "the static libc"? To answer your question about MinGW, here are the default libraries that the linker is instructed to scan when linking a program: -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt Out of these, libgcc.a is a static library that comes with GCC, libmingw32.a and libmingwex.a are static libraries specific to MinGW (the former includes the startup modules like CRTglob, the latter math functions and a few MinGW replacements for missing or buggy functions from the MS runtime), libmoldname.a is a static library of stubs that provide FOO where MS runtime only has _FOO (like _access, _dup2, etc.), and all the rest are Windows dynamic libraries; MinGW just supplies import libs for them. I hope this answers your question about the organization of the MinGW libraries. IIUC, the above means MinGW does not have any "static libc", so it must link against the dynamic libraries that constitute the MS runtime. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 14:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132110826624285 (code B ref 9960); Sat, 12 Nov 2011 14:32:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 14:31:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPEbp-0006Je-Qi for submit@debbugs.gnu.org; Sat, 12 Nov 2011 09:31:06 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPEbm-0006J7-4D for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 09:31:03 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUJ00J00WJD7F00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 16:29:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUJ00ID8XLVQ8K0@a-mtaout20.012.net.il>; Sat, 12 Nov 2011 16:29:56 +0200 (IST) Date: Sat, 12 Nov 2011 16:27:59 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fwhtfma8.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Fri, 11 Nov 2011 20:28:21 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > +++ lisp/bindings.el 2011-11-10 17:49:35 +0000 > > > @@ -824,13 +824,13 @@ > > > ;; Define control-digits. > > > (let ((i ?0)) > > > (while (<= i ?9) > > > - (define-key global-map (read (format "[?\\C-%c]" i)) > > 'digit-argument) > > > +; (define-key global-map (read (format "[?\\C-%c]" i)) > > 'digit-argument) > > > (setq i (1+ i)))) > > > (define-key global-map [?\C--] 'negative-argument) > > > ;; Define control-meta-digits. > > > (let ((i ?0)) > > > (while (<= i ?9) > > > - (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument) > > > +; (define-key esc-map (read (format "[?\\C-%c]" i)) 'digit-argument) > > > (setq i (1+ i)))) > > > (define-key global-map [?\C-\M--] 'negative-argument) > > > > Why is this part needed? > > > > I would like to know. I get an error when bootstrapping at these lines : > invalid read syntax. > If someone has a suggestion on how to investigate it, I'd like to hear it: > > Loading bindings (source)... > Invalid read syntax: "?" > NMAKE : fatal error U1077: > 'C:\Source\XEmTeX\mirror\emacs\src/obj-spd/i386/temacs.exe' : return code > '0xffffffff' > Stop. > NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\Bin\nmake.exe"' : return code '0x2' > Stop. This error comes from the following fragment in lread.c:read1 case '?': { int modifiers; int next_char; int ok; c = READCHAR; if (c < 0) end_of_file_error (); /* Accept `single space' syntax like (list ? x) where the whitespace character is SPC or TAB. Other literal whitespace like NL, CR, and FF are not accepted, as there are well-established escape sequences for these. */ if (c == ' ' || c == '\t') return make_number (c); if (c == '\\') c = read_escape (readcharfun, 0); modifiers = c & CHAR_MODIFIER_MASK; c &= ~CHAR_MODIFIER_MASK; if (CHAR_BYTE8_P (c)) c = CHAR_TO_BYTE8 (c); c |= modifiers; next_char = READCHAR; ok = (next_char <= 040 || (next_char < 0200 && strchr ("\"';()[]#?`,.", next_char) != NULL)); UNREAD (next_char); if (ok) return make_number (c); invalid_syntax ("?"); <<<<<<<<<<<<<<<<<< } Can you step through this in a debugger and see what character is seen in next_char at the end of this snippet, and what value is in `c' at that point, when it fails? The function read_escape called by this fragment could also be of interest. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132110854924674 (code B ref 9960); Sat, 12 Nov 2011 14:36:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 14:35:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPEgP-0006Pv-E4 for submit@debbugs.gnu.org; Sat, 12 Nov 2011 09:35:49 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPEgM-0006Pi-Gv for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 09:35:48 -0500 Received: by bkbzv15 with SMTP id zv15so4042153bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 06:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=e/z7PSDWG6ei/ARQQ5bzd9nvSv8xR+UANVGJlzsra0g=; b=bPkEHlYxizdUQhzBPi7eDou/qsdgAQCfC1MnMQtuD3SKOnaV95KFUw+UaJLvcoKyeS KWzZLSWDNe78rD0C/G6bLgpGsX+8VOM/5S3Nswp6pGGd3Y4JV/Bh2MkZp+5eoMnn2br2 UQg0EBL7kUbVqtHBWkTx3P8wH78oKaX2+hAvY= Received: by 10.204.7.144 with SMTP id d16mr12138806bkd.70.1321108518157; Sat, 12 Nov 2011 06:35:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 06:34:56 -0800 (PST) In-Reply-To: <83hb29fo0k.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> <83hb29fo0k.fsf@gnu.org> From: Fabrice Popineau Date: Sat, 12 Nov 2011 15:34:56 +0100 X-Google-Sender-Auth: p77j_a6It-KET7wlYA7jNN3h84E Message-ID: Content-Type: multipart/alternative; boundary=001517588cfaef3dbd04b18a8bce X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --001517588cfaef3dbd04b18a8bce Content-Type: text/plain; charset=ISO-8859-1 > > > 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 --001517588cfaef3dbd04b18a8bce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> So, I have rebuilt emacs with the static libc. It is working t= oo,
> except for nt/cmdproxy that required :
>
> =3D=3D=3D modified file 'nt/cmdproxy.c'
> --- nt/cmdproxy.c =A0 =A0 =A0 2011-04-27 04:19:15 +0000
> +++ nt/cmdproxy.c =A0 =A0 =A0 2011-11-11 20:41:37 +0000
> @@ -46,6 +46,8 @@
> =A0#define stdout GetStdHandle (STD_OUTPUT_HANDLE)
> =A0#define stderr GetStdHandle (STD_ERROR_HANDLE)
>
> +#ifndef _MSC_VER
> +
> =A0int
> =A0vfprintf (HANDLE hnd, const char * msg, va_list args)
> =A0{
> @@ -81,6 +83,7 @@
>
> =A0 =A0return rc;
> =A0}
> +#endif /* _MSC_VER */
>
> =A0void
> =A0fail (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. =A0By the way, I don't know how the MingW librari= es
> 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. =A0So 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. =A0E.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


The main difference between both is t= hat in the event you compile your program in several modules, and each of t= hese modules need a C library, if you use msvcrt, then internal variables o= f 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 f= or functions like strtok for example).

Also, to complete what I wrote previously about install= ation and redistributables.=A0
It is perfectly possible to compil= e a foo.exe program and link it with the current release
of msvcr= t (say msvcrt100.dll) and pack this library in the very same directory=A0
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 anywh= ere else.

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

=A0-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
=A0-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. =A0I hope this answers your question
about the organization of the MinGW libraries. =A0IIUC, the above means
MinGW does not have any "static libc", so it must link against th= e
dynamic libraries that constitute the MS runtime.

Ok, thanks for this detailed explanation.=A0
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 sou= rce code states that :

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

/******* =A0Mock C library routines =A0*****= ****************************/

/* These routines ar= e used primarily to minimize the executable size. =A0*/

I don't see exactly how to minimze executable size = except by not linking=A0
with any C library. It would be possible= to replace the other string functions
used in cmdproxy.c=A0by Wi= n32 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 fac= t that
they conflict when I link against the static libc.
(Not sure why they don't when linking with msvcrt, I bet it is bec= ause of an underscore again).

Greetings,

--
Fabrice
--001517588cfaef3dbd04b18a8bce-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132111358832404 (code B ref 9960); Sat, 12 Nov 2011 16:00:02 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 15:59:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPFzf-0008Qb-Nt for submit@debbugs.gnu.org; Sat, 12 Nov 2011 10:59:48 -0500 Received: from impaqm2.telefonica.net ([213.4.138.18] helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPFza-0008QO-E2 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 10:59:45 -0500 Received: from IMPmailhost1.adm.correo ([10.20.102.38]) by IMPaqm2.telefonica.net with bizsmtp id wFuT1h01i0piX6q3MFzHYJ; Sat, 12 Nov 2011 16:59:17 +0100 Received: from qcore ([83.57.124.7]) by IMPmailhost1.adm.correo with BIZ IMP id wFzG1h00309hPnX1hFzHcm; Sat, 12 Nov 2011 16:59:17 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> <83hb29fo0k.fsf@gnu.org> Date: Sat, 12 Nov 2011 16:59:15 +0100 In-Reply-To: (Fabrice Popineau's message of "Sat, 12 Nov 2011 15:34:56 +0100") Message-ID: <87aa8172ng.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) Fabrice Popineau 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] From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 17:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13211178816052 (code B ref 9960); Sat, 12 Nov 2011 17:12:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 17:11:21 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPH6u-0001ZY-78 for submit@debbugs.gnu.org; Sat, 12 Nov 2011 12:11:21 -0500 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPH6s-0001ZJ-43 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 12:11:19 -0500 Received: by iaeo4 with SMTP id o4so5333518iae.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 09:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+gsAEQA9TlW04Z1jPW96a2i6+JMO6A20HlxcCHG3WQk=; b=kVJTNUM0OCkPc2GWn+uXoUL4XdXBzWm3UFJjeYp5jYQw6h/EbvGEwjQGKpnrZRhZhx GovB89MaKgT4b9zLi/MmNrAsmA0gNY5BTDhS2nD83Jc/5WSHs8iRl6gzxYvR9GJXrRvp YZwalBEDrNJ597Nm3OC9wHoAxJdf330gpHH5g= Received: by 10.42.151.68 with SMTP id d4mr16747859icw.36.1321117849596; Sat, 12 Nov 2011 09:10:49 -0800 (PST) Received: from [192.168.1.5] (71-208-64-30.hlrn.qwest.net. [71.208.64.30]) by mx.google.com with ESMTPS id el2sm21420043ibb.10.2011.11.12.09.10.47 (version=SSLv3 cipher=OTHER); Sat, 12 Nov 2011 09:10:48 -0800 (PST) Message-ID: <4EBEA88A.6030501@gmail.com> Date: Sat, 12 Nov 2011 10:10:34 -0700 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) 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 = 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? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 17:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132112059110026 (code B ref 9960); Sat, 12 Nov 2011 17:57:02 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 17:56:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPHod-0002be-Bz for submit@debbugs.gnu.org; Sat, 12 Nov 2011 12:56:31 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPHoa-0002bQ-74 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 12:56:29 -0500 Received: by bkbzv15 with SMTP id zv15so4164506bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 09:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OmUBD4bcK4Wvok/j/mtNQOQ7rYDLAsg+ydHphdFDySw=; b=jtDeSrq5VVO1jnZn77vKFX4LdZGJF5mE/hGm7ubN4mofV/Ejb4GeNTo19KErpxrGXU 9ypm3X/ZxqYKRVnRYg5Uyj9g8w7veYJvV/ptXI+V9fhrLYuB6S7DAuPoYyvBhVCk16z+ 5dTw0WHO7+j//oXvf5100sMdCEGQY00sRteeQ= Received: by 10.204.7.144 with SMTP id d16mr12641940bkd.70.1321120559105; Sat, 12 Nov 2011 09:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 09:55:37 -0800 (PST) In-Reply-To: <83fwhtfma8.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> From: Fabrice Popineau Date: Sat, 12 Nov 2011 18:55:37 +0100 X-Google-Sender-Auth: p0zJQlSozoj3Y_-I7-FoKwE3b1w Message-ID: Content-Type: multipart/alternative; boundary=001517588cfaa187ab04b18d59b4 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --001517588cfaa187ab04b18d59b4 Content-Type: text/plain; charset=ISO-8859-1 > > 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 --001517588cfaa187ab04b18d59b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can you step thr= ough 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? =A0The function read_escape called by this
fragment could also be of interest.

Something seems to be messed up in the re= ad_escape function :
it should read the string "[?\\C-0]"=A0<= /div>
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,=A0
next_char =3D = 0x00000030
and c =3D 0x04000030

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

Greetings,

--
Fabri= ce
--001517588cfaa187ab04b18d59b4-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 20:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Christoph Scholtes Cc: fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132113042827080 (code B ref 9960); Sat, 12 Nov 2011 20:41:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 20:40:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPKNI-00072h-FK for submit@debbugs.gnu.org; Sat, 12 Nov 2011 15:40:28 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPKNF-00072U-41 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 15:40:26 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LUK00J00EM6FR00@a-mtaout21.012.net.il> for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 22:39:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUK00JCAEQHBH50@a-mtaout21.012.net.il>; Sat, 12 Nov 2011 22:39:54 +0200 (IST) Date: Sat, 12 Nov 2011 22:37:58 +0200 From: Eli Zaretskii In-reply-to: <4EBEA88A.6030501@gmail.com> X-012-Sender: halo1@inter.net.il Message-id: <83boshf55l.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <4EBEA88A.6030501@gmail.com> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Sat, 12 Nov 2011 10:10:34 -0700 > From: Christoph Scholtes > CC: Eli Zaretskii , 9960@debbugs.gnu.org > > On a clean checkout or after make maintainer-clean `getopt.h' needs to > be regenerated. In order for this to work with nmake I needed to make > the following change: > > === modified file 'lib/makefile.w32-in' > --- lib/makefile.w32-in 2011-11-05 11:34:56 +0000 > +++ lib/makefile.w32-in 2011-11-06 13:34:03 +0000 > @@ -212,7 +212,7 @@ > > HAVE_GETOPT_H = HAVE_GETOPT_H > INCLUDE_NEXT = include_next > -PRAGMA_SYSTEM_HEADER = \#pragma GCC system_header > +PRAGMA_SYSTEM_HEADER = ^#pragma GCC system_header > PRAGMA_COLUMNS = > NEXT_GETOPT_H = > 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@"). From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 20:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132113106228004 (code B ref 9960); Sat, 12 Nov 2011 20:52:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 20:51:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPKXV-0007HS-Tk for submit@debbugs.gnu.org; Sat, 12 Nov 2011 15:51:02 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPKXT-0007H5-30 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 15:51:00 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUK00M00F3D7N00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 22:49:58 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUK00MHXF777310@a-mtaout22.012.net.il>; Sat, 12 Nov 2011 22:49:56 +0200 (IST) Date: Sat, 12 Nov 2011 22:48:00 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83aa81f4ov.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Fabrice Popineau > Date: Sat, 12 Nov 2011 18:55:37 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > Something seems to be messed up in the read_escape function : > it should read the string "[?\\C-0]" > it reads the 'C' and the '-', then it returns the char '0' + ctrl_modifier, > and back in read1, the next char read is '0' again. > Which means that in read1 at the failure point, > next_char = 0x00000030 > and c = 0x04000030 > > I tried to step inside read_escape, but not sure what's going wrong here. Can you show how the values of the following variables change as you step through this fragment in read1 and inside read_escape it calls? read_from_string_index read_from_string_index_byte read_from_string_limit From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 22:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13211368926933 (code B ref 9960); Sat, 12 Nov 2011 22:29:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 22:28:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPM3Y-0001nm-1H for submit@debbugs.gnu.org; Sat, 12 Nov 2011 17:28:12 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPM3V-0001nY-87 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 17:28:10 -0500 Received: by bkbzv15 with SMTP id zv15so4325095bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 14:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=dOm2VkH/eUakLyv1Jy/kR9fnQXsHrFHGVWUDy+u9fJ8=; b=VamrAVx8x0MnDS5dIF3o2dTU1It+at9tGe7prC2HcwBXN3fvFIT9q/s5xJG5DS3NLz +OzlI4InqDtTQfQ7wxltt7Onm7G6gCrWWbwa3Vpw34ioq4YRSuK6pz0+7BqVVZip3cIy 2T9/j7Io86kB/zbcD81xm36BXFnQUsiO/rvlk= Received: by 10.204.157.154 with SMTP id b26mr6089041bkx.52.1321136859115; Sat, 12 Nov 2011 14:27:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 14:27:18 -0800 (PST) In-Reply-To: <83aa81f4ov.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> <83aa81f4ov.fsf@gnu.org> From: Fabrice Popineau Date: Sat, 12 Nov 2011 23:27:18 +0100 X-Google-Sender-Auth: 1TsLZqpnU5T2RNBgZiLE3deRcw8 Message-ID: Content-Type: multipart/alternative; boundary=0015175dd9e22ff21604b1912540 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --0015175dd9e22ff21604b1912540 Content-Type: text/plain; charset=ISO-8859-1 > > 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 --0015175dd9e22ff21604b1912540 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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?

=A0read_from_string_index
=A0read_from_string_index_byte
=A0read_from_string_limit

c= 0x00000043 int
read_from_string_index 0x00000004 int
read_from_string_index_b= yte 0x00000004 int
read_from_string_limit 0x00000008 int

case 'C':
=A0 c =3D READCHAR;

c 0x0000002d int
r= ead_from_string_index 0x00000005 int
read= _from_string_index_byte 0x00000005 int
read= _from_string_limit= 0x00000008= int

=A0 =A0 =A0 if (c !=3D '-')
error (&= quot;Invalid escape character syntax");
=A0 =A0 case '^&= #39;:
=A0 =A0 =A0 c =3D READCHAR;

c 0x00000030 int
r= ead_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 =3D c & CHAR_MODIFIER_MA= SK;
c &am= p;=3D ~CHAR_MODIFIER_MASK;
if (CHAR_BYTE8_P (c))
=A0c =3D CHAR_TO_BYTE8 = (c);
c |= =3D modifiers;

next_char =3D READCHAR;

= c 0x= 04000030 in= t
next_char= 0x00000030= int
<= div> read_= from_string_index = 0x00000007 = int
read= _from_string_index_byte 0x00000007 int
read= _from_string_limit= 0x00000008= int

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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ok =3D 0= =3D> error

Hope you can decipher this.

--
Fabri= ce
--0015175dd9e22ff21604b1912540-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 22:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13211379118410 (code B ref 9960); Sat, 12 Nov 2011 22:46:02 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 22:45:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPMJy-0002Bb-Pj for submit@debbugs.gnu.org; Sat, 12 Nov 2011 17:45:11 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPMJw-0002BP-8c for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 17:45:09 -0500 Received: by bkbzv15 with SMTP id zv15so4332565bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 14:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=bjf6Xc5wflYO8uot1o+vbA/ZuT/AIZghaGLlBzgcdWw=; b=PeEeZgGypXkuSvGo07zlutf6q+FKQPZ68+5YDPbdGduFqlSV02a1lJDYqO1t5WRpOk H3lNPvBOPsxrTf9kvutIqe3YwZe2ganrwR1SFHO2JA6uWsf/mu6AXOQz2xuJ7S98Et6H NKJwXXdwsGsY0RLT9RGbTAxY/RtX5+jdz7sX8= Received: by 10.205.120.145 with SMTP id fy17mr2423245bkc.124.1321137878101; Sat, 12 Nov 2011 14:44:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 14:44:17 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> <83aa81f4ov.fsf@gnu.org> From: Fabrice Popineau Date: Sat, 12 Nov 2011 23:44:17 +0100 X-Google-Sender-Auth: rdNxT-WkgjFpWz2PBqGgE0Bh4-k Message-ID: Content-Type: multipart/alternative; boundary=000e0cdff4b6ec6f8104b1916101 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --000e0cdff4b6ec6f8104b1916101 Content-Type: text/plain; charset=ISO-8859-1 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 --000e0cdff4b6ec6f8104b1916101 Content-Type: text/html; charset=ISO-8859-1 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

--000e0cdff4b6ec6f8104b1916101-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 23:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132113938010488 (code B ref 9960); Sat, 12 Nov 2011 23:10:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 23:09:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPMhg-0002j6-2J for submit@debbugs.gnu.org; Sat, 12 Nov 2011 18:09:40 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPMhe-0002it-CF for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 18:09:39 -0500 Received: by bkbzv15 with SMTP id zv15so4342765bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 15:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=n+M8SRpa4O8gGBtxXV+SBIckzc9Y3H8Gyk/f6NsxjIc=; b=ohbVgqg0TlHdH+yWvStGBeFrpn9K/be4Q/tZEFSuouqawc1fgJL3kMCCUAoUGFe/L9 bGh33RcBf49JW0eEE84wtftEFIzKS8HUaUmwzEzyyztcE65JYFtmhrNeleBkXmeTLtdC +klDkHE3g4wUmuEdlHEVZvSI+JyOJFYzl0WcY= Received: by 10.204.7.71 with SMTP id c7mr13361743bkc.34.1321139348163; Sat, 12 Nov 2011 15:09:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 15:08:47 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> <83aa81f4ov.fsf@gnu.org> From: Fabrice Popineau Date: Sun, 13 Nov 2011 00:08:47 +0100 X-Google-Sender-Auth: I0jAXg3NnwUeeQUra_JbEUqEau8 Message-ID: Content-Type: multipart/alternative; boundary=0015175907fe8bcaec04b191b903 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --0015175907fe8bcaec04b191b903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 > The trick is that the string gets formatted this way : > > s =3D [?\C-00], c=3D 43, index =3D 4, index_byte =3D 4 > > which is definitely wrong. It is format that is failing on this, not read= . > > Fabrice > > --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --0015175907fe8bcaec04b191b903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Solved.

Int nt/inc/stdint.h, there is this co= nstant :

#define UINT32_MAX 4294967296
<= div>
which is obviously wrong and should be :

#define UINT32_MAX 4294967295

Fabrice



2011/11/12 Fabrice Popineau <fabrice.popineau@supelec.fr>
The trick is that the string gets formatted= this way :

s =3D [?\C-00], c=3D 43, index =3D 4, i= ndex_byte =3D 4

which is definitely wrong. It is format that is failing on t= his, not read.

Fabrice




--
Fabri= ce Popineau
-----------------------------
SUPELEC
D= =E9partement Informatique
3, rue Joliot Curie
91192 Gif= /Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212<= /div>
------------------------------


--0015175907fe8bcaec04b191b903-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Richard Stallman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 23:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=D3scar?= Fuentes Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132114080812523 (code B ref 9960); Sat, 12 Nov 2011 23:34:01 +0000 Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 23:33:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPN4h-0003Fv-My for submit@debbugs.gnu.org; Sat, 12 Nov 2011 18:33:27 -0500 Received: from fencepost.gnu.org ([140.186.70.10] ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPN4f-0003Fo-O8 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 18:33:26 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RPN4D-0007jc-L5; Sat, 12 Nov 2011 18:32:58 -0500 Date: Sat, 12 Nov 2011 18:32:57 -0500 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: <87aa8172ng.fsf@wanadoo.es> (message from =?UTF-8?Q?=D3scar?= Fuentes on Sat, 12 Nov 2011 16:59:15 +0100) References: <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> <83hb29fo0k.fsf@gnu.org> <87aa8172ng.fsf@wanadoo.es> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) 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/ From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Nov 2011 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Fabrice Popineau Cc: Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13211955606062 (code B ref 9960); Sun, 13 Nov 2011 14:46:02 +0000 Received: (at 9960) by debbugs.gnu.org; 13 Nov 2011 14:46:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPbJn-0001Zi-Fk for submit@debbugs.gnu.org; Sun, 13 Nov 2011 09:46:00 -0500 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPbJk-0001ZV-06 for 9960@debbugs.gnu.org; Sun, 13 Nov 2011 09:45:57 -0500 Received: by iaeo4 with SMTP id o4so6199915iae.3 for <9960@debbugs.gnu.org>; Sun, 13 Nov 2011 06:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0XtwHVhhaB7aOb2IUY14Nh2CCgT4Jy/f94dWGD8l3a0=; b=SPF5wbQpbAWzB37+C9ige1e99aUYEBkS8DY2JlQzHN1ehUkQrsHK7KSlB4NoyPt2me CutcFgIDX1hWLPh+2e8Ut3yIMG6Sqgp/vVhlyZB5ZtgqG5HPvu6YH8XcIeG+x6CgHWIl QTMhBADVMbExYvHksrTcrESVtFy99HXWSaY5s= Received: by 10.231.83.211 with SMTP id g19mr4446857ibl.26.1321195522309; Sun, 13 Nov 2011 06:45:22 -0800 (PST) Received: from [192.168.1.5] (71-208-64-30.hlrn.qwest.net. [71.208.64.30]) by mx.google.com with ESMTPS id dd36sm25890740ibb.7.2011.11.13.06.45.19 (version=SSLv3 cipher=OTHER); Sun, 13 Nov 2011 06:45:20 -0800 (PST) Message-ID: <4EBFD7FF.3090302@gmail.com> Date: Sun, 13 Nov 2011 07:45:19 -0700 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwhtfma8.fsf@gnu.org> <83aa81f4ov.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) 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... From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 21:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Juanma Barranquero , Eli Zaretskii , cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132182288521127 (code B ref 9960); Sun, 20 Nov 2011 21:02:01 +0000 Received: (at 9960) by debbugs.gnu.org; 20 Nov 2011 21:01:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSEVx-0005Uh-4k for submit@debbugs.gnu.org; Sun, 20 Nov 2011 16:01:25 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSEVu-0005UZ-AM for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 16:01:23 -0500 Received: by bkbzv15 with SMTP id zv15so6429293bkb.3 for <9960@debbugs.gnu.org>; Sun, 20 Nov 2011 13:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=j6XwElQQSlDz/c0HsaOQPS0/Kg3+wwS6uUQN4FEa5ts=; b=Vco66Nf+FXFdzE98KZi6wM6Luzv5ZjBfMOkulucT3rgelCpbK0AhfZRH9rcy088M37 tgyZITfqEjB1dyIWZksoroe2pqWDiUfOvzVvJ4d0gYHetA4ahUbyhIpUZDWIoX2Toc07 am5t/tatCNmLT7zFXBzhgKvrSDdvFaKmWneWY= Received: by 10.205.120.145 with SMTP id fy17mr11805646bkc.124.1321822811195; Sun, 20 Nov 2011 13:00:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.14.14 with HTTP; Sun, 20 Nov 2011 12:59:49 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Fabrice Popineau Date: Sun, 20 Nov 2011 21:59:49 +0100 X-Google-Sender-Auth: -5zO1hU2Nj4iwbvGFwIPIXaxUlk Message-ID: Content-Type: multipart/alternative; boundary=000e0cdff4b61e08dd04b230dbd9 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --000e0cdff4b61e08dd04b230dbd9 Content-Type: text/plain; charset=ISO-8859-1 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 > On Thu, Nov 10, 2011 at 20:56, Fabrice Popineau > wrote: > > > Is there any interest in having a 64bits windows emacs ? > > Yes. > > Juanma > --000e0cdff4b61e08dd04b230dbd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 n= ot declared before being used
(one malloc() use in w32.c, sbrk() = in gmalloc.c), hence they might generate a sign extension, which is not goo= d.

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

Greetings,

=
Fabrice

2011/11/10= Juanma Barranquero <lekktu@gmail.com>
On Thu, Nov 10, 2011 at 2= 0:56, Fabrice Popineau
<fabrice.popineau@supelec= .fr> wrote:

> Is there any interest in having a 64bits windo= ws emacs ?

Yes.

=A0 =A0 Juanma


--000e0cdff4b61e08dd04b230dbd9-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 21:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, Eli Zaretskii , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132182382922493 (code B ref 9960); Sun, 20 Nov 2011 21:18:01 +0000 Received: (at 9960) by debbugs.gnu.org; 20 Nov 2011 21:17:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSElA-0005qk-P8 for submit@debbugs.gnu.org; Sun, 20 Nov 2011 16:17:09 -0500 Received: from mail-pz0-f50.google.com ([209.85.210.50]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSEl9-0005qc-1t for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 16:17:07 -0500 Received: by pzk5 with SMTP id 5so11348143pzk.9 for <9960@debbugs.gnu.org>; Sun, 20 Nov 2011 13:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=y9b1hYSj85TqIYoW+roZgjc7R0bhBPIwuZAp6THcK34=; b=S03Wb9XHRiRFfL2W+lIE2Jilgy8Hw9bGmtHyFcOc3j4Tzg86ixaokiJ064XsF5yenC EBGMQrWtzexgsXd0GvV7HTEcfy087yCR9OwKs/httkHnQHma06pGwpJVLh+KJ/S80DcI PqaFIlSfqVNgYtmJESsVmULfqabqCudpec7Yc= Received: by 10.68.24.65 with SMTP id s1mr29621883pbf.12.1321823756067; Sun, 20 Nov 2011 13:15:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Sun, 20 Nov 2011 13:15:15 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Juanma Barranquero Date: Sun, 20 Nov 2011 22:15:15 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau 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 b= its > 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. =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Dan Nicolaescu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 21:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Juanma Barranquero Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132182497824205 (code B ref 9960); Sun, 20 Nov 2011 21:37:02 +0000 Received: (at 9960) by debbugs.gnu.org; 20 Nov 2011 21:36:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSF3h-0006IL-QB for submit@debbugs.gnu.org; Sun, 20 Nov 2011 16:36:18 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSF3f-0006ID-63 for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 16:36:15 -0500 Received: from dann by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSF2V-0003qB-Pn; Sun, 20 Nov 2011 16:35:03 -0500 From: Dan Nicolaescu References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> Date: Sun, 20 Nov 2011 16:35:03 -0500 In-Reply-To: (Juanma Barranquero's message of "Sun, 20 Nov 2011 22:15:15 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Juanma Barranquero writes: > On Sun, Nov 20, 2011 at 21:59, Fabrice Popineau > 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... From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 21:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Dan Nicolaescu Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132182535024851 (code B ref 9960); Sun, 20 Nov 2011 21:43:02 +0000 Received: (at 9960) by debbugs.gnu.org; 20 Nov 2011 21:42:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSF9h-0006Sk-W1 for submit@debbugs.gnu.org; Sun, 20 Nov 2011 16:42:30 -0500 Received: from mail-pz0-f50.google.com ([209.85.210.50]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSF9e-0006Sc-Vd for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 16:42:27 -0500 Received: by pzk5 with SMTP id 5so11390449pzk.9 for <9960@debbugs.gnu.org>; Sun, 20 Nov 2011 13:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fh4BwqqVSe23rkLVB3/6uf0BOixaFvRHLo3jzNww9bU=; b=e/KA/4u+XMHb1cMgZBDmKljlNvXCC90ZNbouXCYDa3GIsBFvLqqmCN9/easJaFBs8f McjZq0pq8YsRvyPJmSKL71bvziMEht8j0GppSZtEpNmQTYGy0ec1e3kIR7lEd7YJNEmI jiA2YvK6SkePnKgWbknMbb2iNenH6nrIVS0gU= Received: by 10.68.31.129 with SMTP id a1mr30057554pbi.131.1321825276096; Sun, 20 Nov 2011 13:41:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Sun, 20 Nov 2011 13:40:35 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Juanma Barranquero Date: Sun, 20 Nov 2011 22:40:35 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Sun, Nov 20, 2011 at 22:35, Dan Nicolaescu wrote: > -Wimplicit-function-declaration has been turned on by default in > configure for more than a year. =C2=A0On GNU/Linux (and probably most oth= er > platforms that use configure+gcc) =C2=A0-Wimplicit-function-declaration d= oes > 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, =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 02:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Juanma Barranquero Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132184269018112 (code B ref 9960); Mon, 21 Nov 2011 02:32:01 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 02:31:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSJfM-0004i3-RI for submit@debbugs.gnu.org; Sun, 20 Nov 2011 21:31:30 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSJfJ-0004hv-Vm for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 21:31:27 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADm2yU5FxIAT/2dsb2JhbABDqj2BBoFyAQEFViMQCw4EIhIUGA0QFLscihcEiBqZeoRL X-IronPort-AV: E=Sophos;i="4.69,544,1315195200"; d="scan'208";a="148746626" Received: from 69-196-128-19.dsl.teksavvy.com (HELO ceviche.home) ([69.196.128.19]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2011 21:30:14 -0500 Received: by ceviche.home (Postfix, from userid 20848) id A2E9E660D4; Sun, 20 Nov 2011 21:30:13 -0500 (EST) From: Stefan Monnier Message-ID: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> Date: Sun, 20 Nov 2011 21:30:13 -0500 In-Reply-To: (Juanma Barranquero's message of "Sun, 20 Nov 2011 22:15:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) >> - 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 02:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Stefan Monnier Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132184362219506 (code B ref 9960); Mon, 21 Nov 2011 02:48:01 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 02:47:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSJuQ-00054Z-FI for submit@debbugs.gnu.org; Sun, 20 Nov 2011 21:47:02 -0500 Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSJuO-000547-4u for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 21:47:00 -0500 Received: by ghrr14 with SMTP id r14so2242789ghr.3 for <9960@debbugs.gnu.org>; Sun, 20 Nov 2011 18:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mzWQcQEhCYpJLexFFh6bJID4yRg4e7Iwr6Gqw/cJOZE=; b=sB2zYWF/Jf9spDPIMGYR+M4OLWOwF7meWJeR7eHqM0ZrIW0UyJtH3onaaivRC6dZTo fJI7IcK1MBHP0h6NwAUF8vq26T+WwbscM3uFmIwp9Eza/QohkScLss0nKjL0Drf7C7/S uEqMycHnDMawlMo0+gCjyI6OJJU/u8VJDelrU= Received: by 10.68.24.65 with SMTP id s1mr31481922pbf.12.1321843548159; Sun, 20 Nov 2011 18:45:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Sun, 20 Nov 2011 18:45:06 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> From: Juanma Barranquero Date: Mon, 21 Nov 2011 03:45:06 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Mon, Nov 21, 2011 at 03:30, Stefan Monnier wr= ote: > 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? =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 03:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Juanma Barranquero Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, monnier@iro.umontreal.ca, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132184766625494 (code B ref 9960); Mon, 21 Nov 2011 03:55:02 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 03:54:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSKxd-0006d9-QK for submit@debbugs.gnu.org; Sun, 20 Nov 2011 22:54:25 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSKxa-0006cY-BB for 9960@debbugs.gnu.org; Sun, 20 Nov 2011 22:54:24 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUZ00A00RL5MJ00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 05:53:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.237.133]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUZ00APPS439Y90@a-mtaout22.012.net.il>; Mon, 21 Nov 2011 05:53:00 +0200 (IST) Date: Mon, 21 Nov 2011 05:51:02 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83wrau9lqx.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Juanma Barranquero > Date: Mon, 21 Nov 2011 03:45:06 +0100 > Cc: cschol2112@googlemail.com, Fabrice Popineau , > 9960@debbugs.gnu.org > > On Mon, Nov 21, 2011 at 03:30, Stefan Monnier 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 08:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, Juanma Barranquero , fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132186379520398 (code B ref 9960); Mon, 21 Nov 2011 08:24:01 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 08:23:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSP9m-0005Ix-KJ for submit@debbugs.gnu.org; Mon, 21 Nov 2011 03:23:15 -0500 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSP9k-0005Ip-Mn for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 03:23:13 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id BBD6B1C0C168; Mon, 21 Nov 2011 09:21:58 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 5BC601C00105; Mon, 21 Nov 2011 09:21:58 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id SIn2NYC3ptP3; Mon, 21 Nov 2011 09:21:54 +0100 (CET) Received: from hase.home (ppp-93-104-134-85.dynamic.mnet-online.de [93.104.134.85]) by mail.mnet-online.de (Postfix) with ESMTP; Mon, 21 Nov 2011 09:21:53 +0100 (CET) From: Andreas Schwab References: <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> X-Yow: .. My pants just went on a wild rampage through a Long Island Bowling Alley!! Date: Mon, 21 Nov 2011 09:21:53 +0100 In-Reply-To: <83wrau9lqx.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Nov 2011 05:51:02 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Eli Zaretskii writes: > 64-bit Posix hosts (which have the LP64 architecture), There is no connection between POSIX and LP64. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 09:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Andreas Schwab Cc: cschol2112@googlemail.com, lekktu@gmail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132186933128748 (code B ref 9960); Mon, 21 Nov 2011 09:56:01 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 09:55:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSQb4-0007Tb-2t for submit@debbugs.gnu.org; Mon, 21 Nov 2011 04:55:31 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSQb1-0007TU-Kn for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 04:55:28 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSQZo-0005Sw-TP; Mon, 21 Nov 2011 04:54:12 -0500 Date: Mon, 21 Nov 2011 04:54:12 -0500 Message-Id: From: Eli Zaretskii In-reply-to: (message from Andreas Schwab on Mon, 21 Nov 2011 09:21:53 +0100) References: <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Andreas Schwab > Cc: Juanma Barranquero , cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > Date: Mon, 21 Nov 2011 09:21:53 +0100 > > Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 12:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, monnier@iro.umontreal.ca, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13218777939068 (code B ref 9960); Mon, 21 Nov 2011 12:17:02 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 12:16:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSSnY-0002MC-J6 for submit@debbugs.gnu.org; Mon, 21 Nov 2011 07:16:33 -0500 Received: from mail-yw0-f44.google.com ([209.85.213.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSSnV-0002M1-NE for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 07:16:31 -0500 Received: by ywt34 with SMTP id 34so4521776ywt.3 for <9960@debbugs.gnu.org>; Mon, 21 Nov 2011 04:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XTJ321w5N92BMW2hfVf3j40NOPOrQ559pGj8aUvU050=; b=QTMV2lAf6LQn0hElzPH4piDi6oZVnwHycU4DcIc8H2+oH7p0sRO5uCYfoTz1EUULOa x8Kk8knRgC2JIuDALwvMWmTp+fR8GfqgfDn99+o5eHW3dqwywF6SdYRV8mehA8p90k/O BlaaI3JoqSw38JHNO39lhNjGEM/ZGpG3DtB6g= Received: by 10.68.122.169 with SMTP id lt9mr30704252pbb.114.1321877715112; Mon, 21 Nov 2011 04:15:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.48.12 with HTTP; Mon, 21 Nov 2011 04:14:33 -0800 (PST) In-Reply-To: <83wrau9lqx.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> From: Juanma Barranquero Date: Mon, 21 Nov 2011 13:14:33 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii wrote: > The hidden assumption is that a long and a pointer are of the same > width. =C2=A0This is true on 32-bit hosts and on 64-bit Posix hosts (whic= h > 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". =C2=A0 =C2=A0 Juanma From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Juanma Barranquero Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, monnier@iro.umontreal.ca, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132188389420919 (code B ref 9960); Mon, 21 Nov 2011 13:59:02 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 13:58:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSUNx-0005RJ-67 for submit@debbugs.gnu.org; Mon, 21 Nov 2011 08:58:13 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSUNp-0005R3-B5 for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 08:58:06 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSUMc-0001U8-JO; Mon, 21 Nov 2011 08:56:50 -0500 Date: Mon, 21 Nov 2011 08:56:50 -0500 Message-Id: From: Eli Zaretskii In-reply-to: (message from Juanma Barranquero on Mon, 21 Nov 2011 13:14:33 +0100) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Juanma Barranquero > Date: Mon, 21 Nov 2011 13:14:33 +0100 > Cc: monnier@iro.umontreal.ca, cschol2112@googlemail.com, > fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org > > On Mon, Nov 21, 2011 at 04:51, Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Richard Stallman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2011 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, lekktu@gmail.com, eliz@gnu.org, 9960@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132189102932237 (code B ref 9960); Mon, 21 Nov 2011 15:58:02 +0000 Received: (at 9960) by debbugs.gnu.org; 21 Nov 2011 15:57:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSWEx-0008Nm-Vt for submit@debbugs.gnu.org; Mon, 21 Nov 2011 10:57:09 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSWEq-0008NG-49 for 9960@debbugs.gnu.org; Mon, 21 Nov 2011 10:57:01 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSWDb-0000ro-FO; Mon, 21 Nov 2011 10:55:39 -0500 Date: Mon, 21 Nov 2011 10:55:39 -0500 Message-Id: Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman In-reply-to: (message from Fabrice Popineau on Sun, 20 Nov 2011 21:59:49 +0100) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) 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/ From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Nov 2011 19:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13224208365346 (code B ref 9960); Sun, 27 Nov 2011 19:08:01 +0000 Received: (at 9960) by debbugs.gnu.org; 27 Nov 2011 19:07:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUk4J-0001OA-Be for submit@debbugs.gnu.org; Sun, 27 Nov 2011 14:07:15 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUk4G-0001O1-By for 9960@debbugs.gnu.org; Sun, 27 Nov 2011 14:07:13 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LVC0000028XGT00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sun, 27 Nov 2011 21:05:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.205.148]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVC00MAI2CIVZD0@a-mtaout22.012.net.il>; Sun, 27 Nov 2011 21:05:07 +0200 (IST) Date: Sun, 27 Nov 2011 21:05:11 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fwh975eg.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Fabrice Popineau > Date: Thu, 10 Nov 2011 20:56:11 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > Sure. feel free to adapt on the basis of the attached patch. > Status is : > - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able to > boostrap itself. > - the 64 bits version compiles and dumps, but fails to bootstrap (seems to > be looping inside elisp code). > > Is there any interest in having a 64bits windows emacs ? > > I have added two other files : a 64bits manifest for emacs.exe and a > w32compat.h header file that is needed to compile the above mentioned > libraries. In my case, this w32compat.h is included while compiling image.c > for example. > > Feel free to comment and adapt for the release version. Thanks. I think I made all the changes needed for the MSVC 32-bit build. You can try the latest bzr trunk, the changes are in revision 106533. The next pretest of Emacs 24 is expected to be available tomorrow, so if you can try building that and reporting back, that'd be swell. I'm leaving this bug open for now, in case I goofed and it still doesn't build. Please note that only some of the _WIN64 changes are committed. I didn't want to rock the boat too much during the pretest, and also I really feel that we've exceeded the amount of changes we can accept without legal papers. (I'd really encourage you to sign papers at some point, to make all this line-counting business unnecessary.) And I understand that you don't have a fully functional 64-bit version anyway. So I only committed those _WIN64 related changes that fix what we already had in the repository. The rest will have to wait for after the release of Emacs 24.1. Thank you for your help so far. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: YAMAMOTO Mitsuharu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Nov 2011 09:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, Fabrice Popineau , 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132247205516371 (code B ref 9960); Mon, 28 Nov 2011 09:21:02 +0000 Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 09:20:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUxOQ-0004G0-In for submit@debbugs.gnu.org; Mon, 28 Nov 2011 04:20:54 -0500 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUxON-0004Fr-Ha for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 04:20:53 -0500 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 400E6C055D; Mon, 28 Nov 2011 18:18:55 +0900 (JST) Date: Mon, 28 Nov 2011 18:18:54 +0900 Message-ID: From: YAMAMOTO Mitsuharu In-Reply-To: <83fwh975eg.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?UTF-8?Q?Shij=C5=8D?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Sun, 27 Nov 2011 21:05:11 +0200, Eli Zaretskii 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. =3D=3D=3D 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 =3D 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 =A1main=A2: .../lib-src/emacsclient.c:1639: error: =A1environ=A2 undeclared (first use = in this function) .../lib-src/emacsclient.c:1639: error: (Each undeclared identifier is repor= ted only once .../lib-src/emacsclient.c:1639: error: for each function it appears in.) make[2]: *** [emacsclient] Error 1 make[1]: *** [lib-src] Error 2 make: *** [bootstrap] Error 2 YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: "emacsclient.c (main) : Remove declaration," breaks build on Mac OS X References: <8339e2lsu7.fsf@gnu.org> In-Reply-To: <8339e2lsu7.fsf@gnu.org> Resent-From: David Caldwell Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Nov 2011 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132247301817803 (code B ref 9960); Mon, 28 Nov 2011 09:37:02 +0000 Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 09:36:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUxdx-0004d5-Px for submit@debbugs.gnu.org; Mon, 28 Nov 2011 04:36:58 -0500 Received: from sa38.galvanix.net ([98.126.48.38] helo=kill.porkrind.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUxdt-0004cv-02 for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 04:36:55 -0500 Received: from porkrind.org (cpe-66-74-178-118.socal.res.rr.com [66.74.178.118]) by kill.porkrind.org (Postfix) with ESMTPS id B57A95F11C; Mon, 28 Nov 2011 01:34:54 -0800 (PST) Authentication-Results: kill.porkrind.org; dkim=pass (1536-bit key; insecure key) header.i=@porkrind.org header.b=PcaK+4ne; dkim-adsp=pass Received-SPF: pass (porkrind.org: authenticated connection) receiver=porkrind.org; client-ip=127.0.0.1; helo=black.porkrind.org; envelope-from=david@porkrind.org; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from black.porkrind.org (localhost [127.0.0.1]) (authenticated bits=0) by porkrind.org (8.14.4/8.14.4/Debian-2) with ESMTP id pAS9Yrme010346 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 28 Nov 2011 01:34:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=porkrind.org; s=apoptygma; t=1322472895; bh=ccP9JyoyUbCegnblFIMjfnY04TCPzb+Q5Ez7aPisPtg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=PcaK+4neKqruhw0ueWUZ6nxjCHFc7rnRdMQ1McRc57tKVhB0En0Mw3bQbIr1AHl53 J87juvnc4WFdAUdF7OnDzKFgwNsDVqLxV6pT8daMsobZPzNwDxl/7DA2BICp13ssTV JduulNL/nbgFPSUHzhs3zncqgDBsiZQ8UaTYZwnT1994dwgOMm/4RpgQfMRnLBCtUP 9x5Dk6UwqQrlqPQ3rwfgL57N95VGOSz63FXzqfwrT2Jff6o4sCmhHUn+1sr Message-ID: <4ED355B8.60006@porkrind.org> Date: Mon, 28 Nov 2011 01:34:48 -0800 From: David Caldwell User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 X-Enigmail-Version: 1.3.3 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAQAAAD9CzEMAAAACXBIWXMAAAsTAAALEwEAmpwY AAAABGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+S X8VGAAABiklEQVR42rRYSZIDIQwzLv7/ZXLoEAzeBKG7ag4DRhZeBKQ0Qr5imLWCrKwn0HImc1Mx aAvmmc/cuAT7RMYws6v/gHeb0p4/y5792GJJlLZWOPgsdV5NaRes4Xe4632sLljD7wKv1Ta74H/h MxecN1Rc2TatYcP7zb+6WFfN/zMSHg1Ymuxjrzd+DuLw6Nlekggt1hvr7KK9tRIX85jjM6GTYhfv nzXH3jBdYc4koueBs66M+Xv9O9n5ML4urWssjGeMY3if3bzGSvk30BQ46OOaxJjLCpzPJAzXrOrD z5VFh58TIiwESIiCHNxxwPTy97qDei8YdpVdyYEv6EQcK8n+iTyE/Cn1eoe7HwN+F56oErVSGtJY Q1sR2ehaUHfjvJuv0tL7qAzEbBmfF2IHrVi8zp9N0pZtQZZHOXp/sLW4+hqKvm3iccaPwP3XgnKX n8/YtVeOsnenRG7VCBFlZ5fe3LOyANCVdGAIwDs7tTXGF4hIk15/iAfSgv2UkNFItSszOG3Ha7r0 GQBerhBkHOAzmQAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig84A5328419A1DF51140B0234" X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_PASS,T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kill.porkrind.org X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig84A5328419A1DF51140B0234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, I get this error when compiling Emacs for Mac OS X (x86_64, i386, and PowerPC): > gcc -mmacosx-version-min=3D10.5 -std=3Dgnu99 -Wimplicit-function-decl= aration -Wold-style-definition -Wdeclaration-after-statement -DHAVE_CONF= IG_H -I. -I../src -I../lib -I/Users/david/src/emacs-dev/emacs-bzr/build-2= 011-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/l= ib-src/../lib -g -O2 /Users/david/src/emacs-dev/emacs-bzr/build-2011-1= 1-28/lib-src/emacsclient.c \ > -DVERSION=3D"\"24.0.91\"" \ > ../lib/libgnu.a -o emacsclient > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.c: In function 'set_local_socket': > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.c:1281: warning: passing argument 2 of 'confstr' discards qualifiers f= rom pointer target type > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.c: In function 'main': > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.c:1639: error: 'environ' undeclared (first use in this function) > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.c:1639: error: (Each undeclared identifier is reported only once > /Users/david/src/emacs-dev/emacs-bzr/build-2011-11-28/lib-src/emacsclie= nt.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 > 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: =3D=3D=3D 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 =3D 0; environ[i]; i++) { Thanks, David --------------enig84A5328419A1DF51140B0234 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQCVAwUBTtNVvKf81MBhyqGFAQiVNgP+OfRRfKaA/APn2nNLlom1Aqbx1sjk0glp iVjyt2e91AqdS9ZufjJ/keAzcO3eoZLJG/cSz77PmhvAsBcSQhltqOm17cvDEfkb bo6zjeAU/W5b1afseDXcHfD/dSS6QbVu1K6dZq0PMLE8bHTIbCDPJEjU/u8B2EtQ poGiBPkL1fU= =SYZb -----END PGP SIGNATURE----- --------------enig84A5328419A1DF51140B0234-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Nov 2011 11:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: YAMAMOTO Mitsuharu Cc: cschol2112@googlemail.com, fabrice.popineau@supelec.fr, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132248119830322 (code B ref 9960); Mon, 28 Nov 2011 11:54:01 +0000 Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 11:53:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUzln-0007sr-RC for submit@debbugs.gnu.org; Mon, 28 Nov 2011 06:53:17 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUzlg-0007sc-OF for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 06:53:09 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RUzjo-0004QG-Ps; Mon, 28 Nov 2011 06:51:08 -0500 Date: Mon, 28 Nov 2011 06:51:08 -0500 Message-Id: From: Eli Zaretskii In-reply-to: (message from YAMAMOTO Mitsuharu on Mon, 28 Nov 2011 18:18:54 +0900) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > Date: Mon, 28 Nov 2011 18:18:54 +0900 > From: YAMAMOTO Mitsuharu > Cc: Fabrice Popineau , > cschol2112@googlemail.com, > 9960@debbugs.gnu.org > > The above change in revno 106533 causes the following error in > compilation on Mac OS X 10.7. I tried autogen.sh, make distclean, and > make bootstrap, but that didn't help. > > .../lib-src/emacsclient.c: In function ¡main¢: > .../lib-src/emacsclient.c:1639: error: ¡environ¢ undeclared (first use in this function) > .../lib-src/emacsclient.c:1639: error: (Each undeclared identifier is reported only once > .../lib-src/emacsclient.c:1639: error: for each function it appears in.) Sorry about that. Which system header declares `environ' on Mac OS X? Does the problem go away if you include that header in emacsclient.c? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: : "emacsclient.c (main) : Remove declaration," breaks build on Mac OS X References: <8339e2lsu7.fsf@gnu.org> In-Reply-To: <8339e2lsu7.fsf@gnu.org> Resent-From: Leon Zhang Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Nov 2011 17:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132250201632380 (code B ref 9960); Mon, 28 Nov 2011 17:41:02 +0000 Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 17:40:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RV5Bf-0008QD-5C for submit@debbugs.gnu.org; Mon, 28 Nov 2011 12:40:15 -0500 Received: from mail-fx0-f44.google.com ([209.85.161.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RV53J-0008Bl-4a for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 12:31:37 -0500 Received: by faap14 with SMTP id p14so390775faa.3 for <9960@debbugs.gnu.org>; Mon, 28 Nov 2011 09:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=eJYaAGSKGjJlR9Y6O4OGpoqa2mjwuuc2vqNNxBqfW7Q=; b=nEhRJpLfEQh/qnMk8ob+wBZ8GOB3Fd0mEqH4mHgpOEBo3QlWVM79PsYirHJYazAcrp ZIhnoJhQpgUyVr8wiQs4yvcl7TvlMjDySIAW0pbaw9fnSRX7M1usmx7iqER+imMzoO/9 mdDDfrBSQCidXb6Vb1BtuIs9vV6hvpDK30IvA= Received: by 10.205.139.11 with SMTP id iu11mr21139728bkc.82.1322501381222; Mon, 28 Nov 2011 09:29:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.181.69 with HTTP; Mon, 28 Nov 2011 09:29:20 -0800 (PST) From: Leon Zhang Date: Tue, 29 Nov 2011 02:29:20 +0900 Message-ID: Content-Type: multipart/mixed; boundary=000e0ce046260af32e04b2ced9a5 X-Spam-Score: -3.6 (---) X-Mailman-Approved-At: Mon, 28 Nov 2011 12:40:14 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --000e0ce046260af32e04b2ced9a5 Content-Type: multipart/alternative; boundary=000e0ce046260af32904b2ced9a3 --000e0ce046260af32904b2ced9a3 Content-Type: text/plain; charset=UTF-8 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. --000e0ce046260af32904b2ced9a3 Content-Type: text/html; charset=UTF-8 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. --000e0ce046260af32904b2ced9a3-- --000e0ce046260af32e04b2ced9a5 Content-Type: application/octet-stream; name="10_mac_environ.patch" Content-Disposition: attachment; filename="10_mac_environ.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvjr0swc0 ZGlmZiAtLWdpdCBhL2xpYi91bmlzdGQuaW4uaCBiL2xpYi91bmlzdGQuaW4uaAppbmRleCA3N2U1 Njc1Li43NTkwODBhIDEwMDY0NAotLS0gYS9saWIvdW5pc3RkLmluLmgKKysrIGIvbGliL3VuaXN0 ZC5pbi5oCkBAIC0zODIsMTcgKzM4MiwxMiBAQCBfR0xfV0FSTl9PTl9VU0UgKGR1cDMsICJkdXAz IGlzIHVucG9ydGFibGUgLSAiCiAjIGlmICFASEFWRV9ERUNMX0VOVklST05ACiAvKiBTZXQgb2Yg ZW52aXJvbm1lbnQgdmFyaWFibGVzIGFuZCB2YWx1ZXMuICBBbiBhcnJheSBvZiBzdHJpbmdzIG9m IHRoZSBmb3JtCiAgICAiVkFSSUFCTEU9VkFMVUUiLCB0ZXJtaW5hdGVkIHdpdGggYSBOVUxMLiAg Ki8KLSMgIGlmIGRlZmluZWQgX19BUFBMRV9fICYmIGRlZmluZWQgX19NQUNIX18KLSMgICBpbmNs dWRlIDxjcnRfZXh0ZXJucy5oPgotIyAgIGRlZmluZSBlbnZpcm9uICgqX05TR2V0RW52aXJvbiAo KSkKLSMgIGVsc2UKLSMgICBpZmRlZiBfX2NwbHVzcGx1cworIyAgaWZkZWYgX19jcGx1c3BsdXMK IGV4dGVybiAiQyIgewotIyAgIGVuZGlmCisjICBlbmRpZgogZXh0ZXJuIGNoYXIgKiplbnZpcm9u OwotIyAgIGlmZGVmIF9fY3BsdXNwbHVzCisjICBpZmRlZiBfX2NwbHVzcGx1cwogfQotIyAgIGVu ZGlmCiAjICBlbmRpZgogIyBlbmRpZgogI2VsaWYgZGVmaW5lZCBHTlVMSUJfUE9TSVhDSEVDSwpA QCAtNDA3LDYgKzQwMiwxMSBAQCBfR0xfV0FSTl9PTl9VU0UgKHJwbF9lbnZpcm9uLCAiZW52aXJv biBpcyB1bnBvcnRhYmxlIC0gIgogIyAgdW5kZWYgZW52aXJvbgogIyAgZGVmaW5lIGVudmlyb24g KCpycGxfZW52aXJvbiAoKSkKICMgZW5kaWYKKyNlbHNlCisjIGlmIGRlZmluZWQgX19BUFBMRV9f ICYmIGRlZmluZWQgX19NQUNIX18KKyMgIGluY2x1ZGUgPGNydF9leHRlcm5zLmg+CisjICBkZWZp bmUgZW52aXJvbiAoKl9OU0dldEVudmlyb24gKCkpCisjIGVuZGlmCiAjZW5kaWYKIAogCg== --000e0ce046260af32e04b2ced9a5-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Nov 2011 19:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13225073898092 (code B ref 9960); Mon, 28 Nov 2011 19:10:01 +0000 Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 19:09:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RV6aL-00026T-D8 for submit@debbugs.gnu.org; Mon, 28 Nov 2011 14:09:49 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RV6aI-00026L-L5 for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 14:09:48 -0500 Received: by bkbzv15 with SMTP id zv15so8642883bkb.3 for <9960@debbugs.gnu.org>; Mon, 28 Nov 2011 11:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=tK46ow/Hvt1arSbNi6OMDFbdAnnOtye473w+1TJllLo=; b=mwELtUHwx/9BFSy82jqiT3xmvJx/oUOU0ebeLbYbZG0jUCP+svnCVG9MXSSPANFAhd pyrLTTupi8afTCrqRN1kS92v5Kzxzkhmi1RrYrzWsh5ME3BBivT69LKJq1bDdVbfNDFM 9d8plYjBpS5YT/xzLHJO+xk5+sB6UmjJ9FAZI= Received: by 10.205.132.146 with SMTP id hu18mr46722551bkc.123.1322507270114; Mon, 28 Nov 2011 11:07:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.132.20 with HTTP; Mon, 28 Nov 2011 11:07:29 -0800 (PST) In-Reply-To: <83fwh975eg.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> From: Fabrice Popineau Date: Mon, 28 Nov 2011 20:07:29 +0100 X-Google-Sender-Auth: g04lPeztd2Zz1hTdumNdmwp94I8 Message-ID: Content-Type: multipart/alternative; boundary=000e0ce02ace0c506f04b2d038e6 X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --000e0ce02ace0c506f04b2d038e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 . Greetings, Fabrice =3D=3D=3D 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 #include +#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 =3D=3D=3D 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 > > From: Fabrice Popineau > > Date: Thu, 10 Nov 2011 20:56:11 +0100 > > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > > Sure. feel free to adapt on the basis of the attached patch. > > Status is : > > - completely functional 32 bits version with xpm, gif, jpeg, tiff. Able > to > > boostrap itself. > > - the 64 bits version compiles and dumps, but fails to bootstrap (seems > to > > be looping inside elisp code). > > > > Is there any interest in having a 64bits windows emacs ? > > > > I have added two other files : a 64bits manifest for emacs.exe and a > > w32compat.h header file that is needed to compile the above mentioned > > libraries. In my case, this w32compat.h is included while compiling > image.c > > for example. > > > > Feel free to comment and adapt for the release version. > > Thanks. I think I made all the changes needed for the MSVC 32-bit > build. You can try the latest bzr trunk, the changes are in revision > 106533. The next pretest of Emacs 24 is expected to be available > tomorrow, so if you can try building that and reporting back, that'd > be swell. > > I'm leaving this bug open for now, in case I goofed and it still > doesn't build. > > Please note that only some of the _WIN64 changes are committed. I > didn't want to rock the boat too much during the pretest, and also I > really feel that we've exceeded the amount of changes we can accept > without legal papers. (I'd really encourage you to sign papers at > some point, to make all this line-counting business unnecessary.) And > I understand that you don't have a fully functional 64-bit version > anyway. So I only committed those _WIN64 related changes that fix > what we already had in the repository. The rest will have to wait for > after the release of Emacs 24.1. > > Thank you for your help so far. > --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --000e0ce02ace0c506f04b2d038e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On my side, there is still this messy 'tzname', which seems to be d= efined in some part an not in some others.
I need the patch below. =A0I= t could probably be eliminated by a careful analysis of what files are incl= uded.
I think the problem is that tzname may be defined to be _tzname _befor= e_ including the regular MS <time.h> .

Greet= ings,

Fabrice


=3D=3D=3D modified file 'lib/strftime.c'
--- li= b/strftime.c =A0 =A0 =A02011-03-31 04:24:03 +0000
+++ lib/strftim= e.c =A0 =A0 =A02011-11-28 15:38:55 +0000
@@ -36,9 +36,13 @@
=
=A0#include <ctype.h>
=A0#include <time.h>

+#ifdef _MSC_VER
+#define tzname _tzname
+#else
=A0#if HAVE_TZN= AME && !HAVE_DECL_TZNAME
=A0extern char *tzname[];
<= div> =A0#endif
+#endif

=A0/* Do multibyte pro= cessing if multibytes are supported, unless
=A0 =A0 multibyte seq= uences are safe in formats. =A0Multibyte sequences are
=3D= =3D=3D modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h =A0 =A0 =A02011-11-27 18:52:53 +0000
+++ = src/s/ms-w32.h =A0 =A0 =A02011-11-28 15:33:33 +0000
@@ -286,7 +28= 6,9 @@
=A0#define stricmp =A0 _stricmp
=A0#define tzset= =A0 =A0 _tzset

+#ifndef _MSC_VER
=A0#define tzname =A0 =A0_t= zname
+#endif
=A0#if !defined (_MSC_VER) || (_MSC_VER &= lt; 1400)
=A0#undef =A0utime
=A0#define utime =A0 =A0_u= time


2011/11/27 Eli Zaretskii <eliz@gnu.org>
> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Thu, 10 Nov 2011 20:56:11 +0100
> Cc: cschol2112@googlemail= .com, 9960@debbugs.gnu.org<= br> >
> Sure. feel free to adapt on the basis of the attached patch.
> Status is :
> - completely functional 32 bits version with xpm, gif, jpeg, tiff. Abl= e 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 windo= ws emacs ?
>
> I have added two other files : a 64bits manife= st for emacs.exe and a
> w32compat.h header file that is needed to compile the above mentioned<= br> > libraries. In my case, this w32compat.h is included while compiling im= age.c
> for example.
>
> Feel free to comment and adapt for the release= version.

Thanks. =A0I think I made all the changes needed for the MSVC 32-bit<= br> build. =A0You can try the latest bzr trunk, the changes are in revision
106533. =A0The 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. =A0I
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. =A0(I'd really encourage you to sign papers at some point, to make all this line-counting business unnecessary.) =A0And I understand that you don't have a fully functional 64-bit version
anyway. =A0So I only committed those _WIN64 related changes that fix
what we already had in the repository. =A0The rest will have to wait for after the release of Emacs 24.1.

Thank you for your help so far.



--
Fabrice Popi= neau
-----------------------------
SUPELEC
D=E9part= ement Informatique
3, rue Joliot Curie
91192 Gif/Yvette= Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212<= /div>
------------------------------


--000e0ce02ace0c506f04b2d038e6-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: OSX breakage Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 09:31:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Chong Yidong Cc: mario@lassnig.net, Eli Zaretskii , 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132255904230102 (code B ref 9960); Tue, 29 Nov 2011 09:31:03 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 09:30:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVK1Q-0007pO-KF for submit@debbugs.gnu.org; Tue, 29 Nov 2011 04:30:41 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVK1H-0007ov-Hg; Tue, 29 Nov 2011 04:30:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D3A47A60003; Tue, 29 Nov 2011 01:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwplGHafoRhy; Tue, 29 Nov 2011 01:28:28 -0800 (PST) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 18218A60001; Tue, 29 Nov 2011 01:28:28 -0800 (PST) Message-ID: <4ED4A5BE.80008@cs.ucla.edu> Date: Tue, 29 Nov 2011 01:28:30 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> In-Reply-To: <871usrh69t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On 11/28/11 21:00, Chong Yidong wrote: > As Eli pointed out in the discussion on bug#10155, there is already cod= e > 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 =3D=3D=3D 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 =3D=3D=3D 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 + + 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=C3=A4rv =20 * configure.in: Check for gtk_window_set_has_resize_grip. =3D=3D=3D 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 =3D \ alloca-opt \ careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoast= r \ - 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 =3D \ --avoid=3Dmsvc-inval --avoid=3Dmsvc-nothrow --avoid=3Dpathmax \ --avoid=3Draise --avoid=3Dthreadlib \ =3D=3D=3D 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\con= fig.in > config.tmp :src4 sed -f ../msdos/sed2v2.inp 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; >j= unk.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_LS= B_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=3D set sys_malloc=3D set libxml=3D - =3D=3D=3D 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 =20 -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=3Dyes], - [emacs_cv_attribute_aligned=3Dno])]) -if test $emacs_cv_attribute_aligned =3D 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 =20 =3D=3D=3D 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 + + * texinfo.tex: Merge from gnulib. + 2011-11-24 Glenn Morris =20 * gnus.texi, smtpmail.texi: Fix case of "GnuTLS". =3D=3D=3D 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{(Inde= x is empty)}\fi @@ -1194,29 +1195,31 @@ \def\imagewidth{#2}\setbox0 =3D \hbox{\ignorespaces #2}% \def\imageheight{#3}\setbox2 =3D \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=3D\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 =3D \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 +} =20 % 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} =20 +\def\aftersmartic{} +\def\var#1{% + \let\saveaftersmartic =3D \aftersmartic + \def\aftersmartic{\null\let\aftersmartic=3D\saveaftersmartic}% + \smartslanted{#1}% +} + \let\i=3D\smartitalic \let\slanted=3D\smartslanted -\def\var#1{\smartslanted{#1}} \let\dfn=3D\smartslanted \let\emph=3D\smartitalic =20 @@ -2480,7 +2491,7 @@ \plainfrenchspacing #1% }% - \null + \null % reset spacefactor to 1000 } =20 % 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=3D1000 } =20 % @abbr for "Comput. J." and the like. @@ -2774,6 +2786,7 @@ \ifx\temp\empty \else \space ({\unsepspaces \ignorespaces \temp \unskip})% \fi + \null % reset \spacefactor=3D1000 } =20 % @asis just yields its argument. Used with @table, for example. @@ -2979,7 +2992,7 @@ {\tentt \global\dimen0 =3D 3em}% Width of the box. \dimen2 =3D .55pt % Thickness of rules % The text. (`r' is open on the right, `e' somewhat less so on the left.= ) -\setbox0 =3D \hbox{\kern-.75pt \reducedsf error\kern-1.5pt} +\setbox0 =3D \hbox{\kern-.75pt \reducedsf \putworderror\kern-1.5pt} % \setbox\errorbox=3D\hbox to \dimen0{\hfil \hsize =3D \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 =3D0 } =20 -% @footnotestyle is meaningful for info output only. +% @footnotestyle is meaningful for Info output only. \let\footnotestyle=3D\comment =20 {\catcode `\@=3D11 @@ -8166,6 +8179,8 @@ % expands into a box, it must come within the paragraph, lest it % provide a place where TeX can split the footnote. \footstrut + % + % Invoke rest of plain TeX footnote routine. \futurelet\next\fo@t } }%end \catcode `\@=3D11 =3D=3D=3D 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 =20 #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \ - (((__GNUC__ >=3D 3 || __GNUG__ >=3D 2) && !__STRICT_ANSI__) \ + (((__GNUC__ >=3D 3 || __GNUG__ >=3D 2) && !defined __STRICT_ANSI__) \ /* || __STDC_VERSION__ >=3D 199901L */ ) =20 #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS =3D=3D=3D 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=3D. --lib=3Dlibgnu --source-b= ase=3Dlib --m4-base=3Dm4 --doc-base=3Ddoc --tests-base=3Dtests --aux-dir=3D= build-aux --avoid=3Dmsvc-inval --avoid=3Dmsvc-nothrow --avoid=3Dpathmax -= -avoid=3Draise --avoid=3Dthreadlib --makefile-name=3Dgnulib.mk --conditio= nal-dependencies --no-libtool --macro-prefix=3Dgl --no-vc-files alloca-op= t careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr= dup2 filemode getloadavg getopt-gnu ignore-value intprops lstat mktime p= thread_sigmask readlink socklen stdarg stdio strftime strtoimax strtoumax= symlink sys_stat +# Reproduce by: gnulib-tool --import --dir=3D. --lib=3Dlibgnu --source-b= ase=3Dlib --m4-base=3Dm4 --doc-base=3Ddoc --tests-base=3Dtests --aux-dir=3D= build-aux --avoid=3Dmsvc-inval --avoid=3Dmsvc-nothrow --avoid=3Dpathmax -= -avoid=3Draise --avoid=3Dthreadlib --makefile-name=3Dgnulib.mk --conditio= nal-dependencies --no-libtool --macro-prefix=3Dgl --no-vc-files alloca-op= t 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 st= rtoimax strtoumax symlink sys_stat =20 =20 MOSTLYCLEANFILES +=3D core *.stackdump @@ -421,6 +421,29 @@ =20 ## end gnulib module stat =20 +## begin gnulib module stdalign + +BUILT_SOURCES +=3D $(STDALIGN_H) + +# We need the following in order to create 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 +=3D stdalign.h stdalign.h-t + +EXTRA_DIST +=3D stdalign.in.h + +## end gnulib module stdalign + ## begin gnulib module stdarg =20 BUILT_SOURCES +=3D $(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_NONBLOC= KING)/g' \ -e 's/@''GNULIB_UNISTD_H_SIGPIPE''@/$(GNULIB_UNISTD_H_SIGPIPE)/g'= \ -e 's/@''GNULIB_UNLINK''@/$(GNULIB_UNLINK)/g' \ =3D=3D=3D 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 @@ =20 #include "md5.h" =20 -#include +#include +#include #include #include #include @@ -254,8 +255,7 @@ if (len >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha1.h" =20 -#include +#include +#include #include #include =20 @@ -241,8 +242,7 @@ if (len >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha256.h" =20 -#include +#include +#include #include #include =20 @@ -51,7 +52,7 @@ =20 /* 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 >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha512.h" =20 -#include +#include +#include #include #include =20 @@ -58,7 +59,7 @@ =20 /* 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 >=3D 128) { #if !_STRING_ARCH_unaligned -# define alignof(type) offsetof (struct { char c; type x; }, x) -# define UNALIGNED_P(p) (((size_t) p) % alignof (u64) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (u64) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 128) { =3D=3D=3D 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 !=3D SIG_IGN) (*handler) (SIGPIPE); } + return 0; } #endif =3D=3D=3D 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 . + + 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 Foundatio= n, + 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 for platforms that lack it. + + References: + ISO C1X + sections 6.5.3.4, 6.7.5, 7.15. + C++0X + 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 +#if defined __cplusplus + template struct __alignof_helper { char __a; __t __b; }; +# define _Alignof(type) offsetof (__alignof_helper, __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 <=3D __SUNPRO_C +# define _Alignas(a) __attribute__ ((__aligned__ (a))) +#elif 1300 <=3D _MSC_VER +# define _Alignas(a) __declspec (align (a)) +#endif +#ifdef _Alignas +# define alignas _Alignas +# define __alignas_is_defined 1 +#endif + +#endif /* _GL_STDALIGN_H */ =3D=3D=3D 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 =20 +#if @GNULIB_POSIX_OPENPT@ +/* Return an FD open to the master side of a pseudo-terminal. Flags sho= uld + 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 =20 +#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) =3D=3D=3D 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 =3D 0; then - REPLACE_DUP2=3D1 + if test $HAVE_DUP2 =3D 1; then + REPLACE_DUP2=3D1 + fi fi ]) ]) =3D=3D=3D 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 to declare environ. + AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) + + AC_CHECK_HEADERS_ONCE([unistd.h]) + gt_CHECK_VAR_DECL( + [#if HAVE_UNISTD_H + #include + #endif + /* mingw, BeOS, Haiku declare environ in , not in . */ + #include + ], + [environ]) + if test $gt_cv_var_environ_declaration !=3D yes; then + HAVE_DECL_ENVIRON=3D0 + 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 =3D 1;]])], + [gt_cv_var=3Dno], + [gt_cv_var=3Dyes])]) + AC_MSG_RESULT([$gt_cv_var]) + if test $gt_cv_var =3D 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]) +]) =3D=3D=3D 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 =3D 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=3D1 fi ]) =20 =3D=3D=3D 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 =3D 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=3D1 fi +AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT]) gl_MODULE_INDICATOR_FOR_TESTS([getopt-gnu]) gl_FUNC_GETOPT_POSIX if test $REPLACE_GETOPT =3D 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=3D1 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 =3D 0 || test $REPLACE_READLINK =3D 1; then func_gl_gnulib_m4code_stat fi - if test $ac_cv_func_strtoimax =3D no; then - func_gl_gnulib_m4code_verify - fi if test $ac_cv_func_strtoimax =3D no && test $ac_cv_type_long_long_int= =3D yes; then func_gl_gnulib_m4code_strtoll fi - if test $ac_cv_func_strtoumax =3D no; then + if test $ac_cv_func_strtoimax =3D no; then func_gl_gnulib_m4code_verify fi if test $ac_cv_func_strtoumax =3D no && test $ac_cv_type_unsigned_long= _long_int =3D yes; then func_gl_gnulib_m4code_strtoull fi + if test $ac_cv_func_strtoumax =3D no; then + func_gl_gnulib_m4code_verify + fi m4_pattern_allow([^gl_GNULIB_ENABLED_]) AM_CONDITIONAL([gl_GNULIB_ENABLED_dosname], [$gl_gnulib_enabled_dosnam= e]) 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 =3D=3D=3D 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 <=3D __GNUC__ || (__GNUC__ =3D=3D 2 && 8 <=3D __GNUC_MINOR__) \ || 0x5110 <=3D __SUNPRO_C) # define _Noreturn __attribute__ ((__noreturn__)) -# elif 1200 <=3D _MSC_VER +# elif defined _MSC_VER && 1200 <=3D _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn =3D=3D=3D 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=3D'[/\\]' ;; *) - gl_dirsep_regex=3D'/' + gl_dirsep_regex=3D'\/' ;; esac + dnl A sed expression that turns a string into a basic reg= ular + dnl expression, for use within "/.../". + gl_make_literal_regex_sed=3D's,[]$^\\.*/[],\\&,g' changequote([,]) - gl_absolute_header_sed=3D'\|'"${gl_dirsep_regex}"']m4_def= n([gl_HEADER_NAME])[|{ - s|.*"\(.*'"${gl_dirsep_regex}"']m4_defn([gl_HEADER_NA= ME])[\)".*|\1| + gl_header_literal_regex=3D`echo ']m4_defn([gl_HEADER_NAME= ])[' \ + | sed -e "$gl_make_literal_regex= _sed"` + gl_absolute_header_sed=3D"/${gl_dirsep_regex}${gl_header_= literal_regex}/"'{ + s/.*"\(.*'"${gl_dirsep_regex}${gl_header_literal_rege= x}"'\)".*/\1/ changequote(,)dnl s|^/[^/]|//&| changequote([,])dnl =3D=3D=3D 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 @@ =20 AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK], [ + AC_REQUIRE([gl_SIGNAL_H_DEFAULTS]) + AC_CHECK_FUNCS_ONCE([pthread_sigmask]) LIB_PTHREAD_SIGMASK=3D =20 =3D=3D=3D 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 if it is not supported. + +AC_DEFUN([gl_STDALIGN_H], +[ + AC_CHECK_HEADERS_ONCE([stdalign.h]) + + if test $ac_cv_header_stdalign_h =3D yes; then + STDALIGN_H=3D'' + else + STDALIGN_H=3D'stdalign.h' + fi + + AC_SUBST([STDALIGN_H]) + AM_CONDITIONAL([GL_GENERATE_STDALIGN_H], [test -n "$STDALIGN_H"]) +]) =3D=3D=3D 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 #endif - ]], [_Exit atoll canonicalize_file_name getloadavg getsubopt grantpt= mkdtemp - mkostemp mkostemps mkstemp mkstemps ptsname random_r initstat_r sran= dom_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 srando= m_r + strtod strtoll strtoull unlockpt unsetenv]) ]) =20 AC_DEFUN([gl_STDLIB_MODULE_INDICATOR], @@ -50,7 +50,9 @@ GNULIB_MKOSTEMPS=3D0; AC_SUBST([GNULIB_MKOSTEMPS]) GNULIB_MKSTEMP=3D0; AC_SUBST([GNULIB_MKSTEMP]) GNULIB_MKSTEMPS=3D0; AC_SUBST([GNULIB_MKSTEMPS]) + GNULIB_POSIX_OPENPT=3D0; AC_SUBST([GNULIB_POSIX_OPENPT]) GNULIB_PTSNAME=3D0; AC_SUBST([GNULIB_PTSNAME]) + GNULIB_PTSNAME_R=3D0; AC_SUBST([GNULIB_PTSNAME_R]) GNULIB_PUTENV=3D0; AC_SUBST([GNULIB_PUTENV]) GNULIB_RANDOM_R=3D0; AC_SUBST([GNULIB_RANDOM_R]) GNULIB_REALLOC_POSIX=3D0; AC_SUBST([GNULIB_REALLOC_POSIX]) @@ -76,7 +78,9 @@ HAVE_MKOSTEMPS=3D1; AC_SUBST([HAVE_MKOSTEMPS]) HAVE_MKSTEMP=3D1; AC_SUBST([HAVE_MKSTEMP]) HAVE_MKSTEMPS=3D1; AC_SUBST([HAVE_MKSTEMPS]) + HAVE_POSIX_OPENPT=3D1; AC_SUBST([HAVE_POSIX_OPENPT]) HAVE_PTSNAME=3D1; AC_SUBST([HAVE_PTSNAME]) + HAVE_PTSNAME_R=3D1; AC_SUBST([HAVE_PTSNAME_R]) HAVE_RANDOM_H=3D1; AC_SUBST([HAVE_RANDOM_H]) HAVE_RANDOM_R=3D1; AC_SUBST([HAVE_RANDOM_R]) HAVE_REALPATH=3D1; AC_SUBST([HAVE_REALPATH]) @@ -95,6 +99,7 @@ REPLACE_MALLOC=3D0; AC_SUBST([REPLACE_MALLOC]) REPLACE_MBTOWC=3D0; AC_SUBST([REPLACE_MBTOWC]) REPLACE_MKSTEMP=3D0; AC_SUBST([REPLACE_MKSTEMP]) + REPLACE_PTSNAME_R=3D0; AC_SUBST([REPLACE_PTSNAME_R]) REPLACE_PUTENV=3D0; AC_SUBST([REPLACE_PUTENV]) REPLACE_REALLOC=3D0; AC_SUBST([REPLACE_REALLOC]) REPLACE_REALPATH=3D0; AC_SUBST([REPLACE_REALPATH]) =3D=3D=3D 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=3D0; AC_SUBST([GNULIB_SYMLINK]) GNULIB_SYMLINKAT=3D0; AC_SUBST([GNULIB_SYMLINKAT]) GNULIB_TTYNAME_R=3D0; AC_SUBST([GNULIB_TTYNAME_R]) - GNULIB_UNISTD_H_GETOPT=3D0; AC_SUBST([GNULIB_UNISTD_H_GETOPT]) GNULIB_UNISTD_H_NONBLOCKING=3D0; AC_SUBST([GNULIB_UNISTD_H_NONBLOCKING= ]) GNULIB_UNISTD_H_SIGPIPE=3D0; AC_SUBST([GNULIB_UNISTD_H_SIGPIPE]) GNULIB_UNLINK=3D0; AC_SUBST([GNULIB_UNLINK]) =3D=3D=3D 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 + + 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 =20 * sed3v2.inp (insrcdir): Comment out definition. =3D=3D=3D 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|^.*$|/* & */| - =3D=3D=3D 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 *=3D/s/@REPLACE_CALLOC@/0/ -#=20 +# # . 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 *=3D/s/@SIZE_T_SUFFIX@/u/ /^ALLOCA_H *=3D/s/@[^@\n]*@/alloca.h/ /^STDBOOL_H *=3D/s/@[^@\n]*@// +/^STDALIGN_H *=3D/s/@[^@\n]*@/stdalign.h/ /^STDARG_H *=3D/s/@[^@\n]*@// /^STDDEF_H *=3D/s/@[^@\n]*@// /^STDINT_H *=3D/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@/\#/ =3D=3D=3D 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 + + Use Gnulib stdalign module (Bug#9772, Bug#9960). + * config.nt (HAVE_ATTRIBUTE_ALIGNED): Remove. + 2011-11-27 Fabrice Popineau (tiny chang= e) =20 * inc/stdint.h (uint32_t, uint64_t) [_WIN64]: New typedefs. =3D=3D=3D 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 @@ =20 /* Preprocessor macros needed for gnulib imports. */ =20 -/* 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 =3D=3D=3D 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 + + 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 . + (DECL_ALIGN): Simplify by using alignas. + Port to MSVC, by using ALIGN_GCTYPEBITS. + (ALIGN_GCTYPEBITS): New macro. + 2011-11-28 Paul Eggert =20 Remove GCPRO-related macros that exist only to avoid shadowing locals. =3D=3D=3D 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 @@ } =20 =20 -/* 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 *) =20 /* 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 =3D (1 << GCTYPEBITS); #else - size_t alignment =3D sizeof (EMACS_INT); + size_t alignment =3D alignof (EMACS_INT); =20 /* Give Lisp_Floats an extra alignment. */ if (type =3D=3D Lisp_Float) - { -#if defined __GNUC__ && __GNUC__ >=3D 2 - alignment =3D __alignof (struct Lisp_Float); -#else - alignment =3D sizeof (struct Lisp_Float); -#endif - } + alignment =3D alignof (struct Lisp_Float); #endif =20 again: =3D=3D=3D 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 =20 +#include #include #include #include @@ -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) !=3D 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 =20 /* 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. */ }; =20 +#ifndef GCTYPEBITS +#define GCTYPEBITS 3 +#define ALIGN_GCTYPEBITS 8 /* This must be an integer constant, for MSVC= . */ +#endif +#if 1 << GCTYPEBITS !=3D 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) From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#10155: OSX breakage Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 13:59:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Paul Eggert Cc: mario@lassnig.net, Chong Yidong , 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132257513224551 (code B ref 9960); Tue, 29 Nov 2011 13:59:03 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 13:58:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVOCw-0006Ns-RG for submit@debbugs.gnu.org; Tue, 29 Nov 2011 08:58:52 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVOCt-0006Ne-H6; Tue, 29 Nov 2011 08:58:48 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pATDucqW009480; Tue, 29 Nov 2011 08:56:39 -0500 Received: by pastel.home (Postfix, from userid 20848) id 6E5D94E758; Tue, 29 Nov 2011 08:56:38 -0500 (EST) From: Stefan Monnier Message-ID: References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> Date: Tue, 29 Nov 2011 08:56:38 -0500 In-Reply-To: <4ED4A5BE.80008@cs.ucla.edu> (Paul Eggert's message of "Tue, 29 Nov 2011 01:28:30 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4055=0 X-NAI-Spam-Version: 2.2.0.9286 : core <4055> : streams <706259> : uri <1018290> X-Spam-Score: -4.4 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) > --- .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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: OSX breakage Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 16:43:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Paul Eggert Cc: mario@lassnig.net, cyd@gnu.org, 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132258495110069 (code B ref 9960); Tue, 29 Nov 2011 16:43:03 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 16:42:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVQlK-0002cH-8i for submit@debbugs.gnu.org; Tue, 29 Nov 2011 11:42:31 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVQlF-0002bq-RZ; Tue, 29 Nov 2011 11:42:27 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LVF00600KVOCX00@a-mtaout20.012.net.il>; Tue, 29 Nov 2011 18:39:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.122.78]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVF001NBKYDOGA1@a-mtaout20.012.net.il>; Tue, 29 Nov 2011 18:39:51 +0200 (IST) Date: Tue, 29 Nov 2011 18:39:56 +0200 From: Eli Zaretskii In-reply-to: <4ED4A5BE.80008@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83obvu6fxf.fsf@gnu.org> References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Tue, 29 Nov 2011 01:28:30 -0800 > From: Paul Eggert > CC: Eli Zaretskii , mario@lassnig.net, > 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#10155: OSX breakage Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 17:01:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Stefan Monnier Cc: mario@lassnig.net, 9960@debbugs.gnu.org, Chong Yidong , 9772@debbugs.gnu.org, 10155@debbugs.gnu.org, Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132258605411697 (code B ref 9960); Tue, 29 Nov 2011 17:01:03 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 17:00:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVR35-00032W-Dh for submit@debbugs.gnu.org; Tue, 29 Nov 2011 12:00:53 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVR2s-000320-U5; Tue, 29 Nov 2011 12:00:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 1B8E8A6000B; Tue, 29 Nov 2011 08:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy-IEH63CpAs; Tue, 29 Nov 2011 08:58:34 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id BC0DCA60001; Tue, 29 Nov 2011 08:58:34 -0800 (PST) Message-ID: <4ED50F3A.8040207@cs.ucla.edu> Date: Tue, 29 Nov 2011 08:58:34 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) 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 >=20 > 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. =3D=3D=3D 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 + + 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=E4rv =20 * configure.in: Check for gtk_window_set_has_resize_grip. =3D=3D=3D 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 =3D \ alloca-opt \ careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoast= r \ - dup2 \ + dup2 environ \ filemode getloadavg getopt-gnu ignore-value intprops lstat \ mktime pthread_sigmask readlink \ socklen stdarg stdio strftime strtoimax strtoumax symlink sys_stat =3D=3D=3D 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 =3D=3D=3D 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=3D set sys_malloc=3D set libxml=3D - =3D=3D=3D 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 + + 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 =20 * sed3v2.inp (insrcdir): Comment out definition. =3D=3D=3D 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 *=3D/s/@REPLACE_CALLOC@/0/ -#=20 +# # . 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 *=3D/s/@SIZE_T_SUFFIX@/u/ /^ALLOCA_H *=3D/s/@[^@\n]*@/alloca.h/ /^STDBOOL_H *=3D/s/@[^@\n]*@// +/^STDALIGN_H *=3D/s/@[^@\n]*@/stdalign.h/ /^STDARG_H *=3D/s/@[^@\n]*@// /^STDDEF_H *=3D/s/@[^@\n]*@// /^STDINT_H *=3D/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@/\#/ =3D=3D=3D 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 + + * texinfo.tex: Sync from gnulib. + 2011-11-24 Glenn Morris =20 * gnus.texi, smtpmail.texi: Fix case of "GnuTLS". =3D=3D=3D 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{(Inde= x is empty)}\fi @@ -1194,29 +1195,31 @@ \def\imagewidth{#2}\setbox0 =3D \hbox{\ignorespaces #2}% \def\imageheight{#3}\setbox2 =3D \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=3D\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 =3D \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 +} =20 % 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} =20 +\def\aftersmartic{} +\def\var#1{% + \let\saveaftersmartic =3D \aftersmartic + \def\aftersmartic{\null\let\aftersmartic=3D\saveaftersmartic}% + \smartslanted{#1}% +} + \let\i=3D\smartitalic \let\slanted=3D\smartslanted -\def\var#1{\smartslanted{#1}} \let\dfn=3D\smartslanted \let\emph=3D\smartitalic =20 @@ -2480,7 +2491,7 @@ \plainfrenchspacing #1% }% - \null + \null % reset spacefactor to 1000 } =20 % 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=3D1000 } =20 % @abbr for "Comput. J." and the like. @@ -2774,6 +2786,7 @@ \ifx\temp\empty \else \space ({\unsepspaces \ignorespaces \temp \unskip})% \fi + \null % reset \spacefactor=3D1000 } =20 % @asis just yields its argument. Used with @table, for example. @@ -2979,7 +2992,7 @@ {\tentt \global\dimen0 =3D 3em}% Width of the box. \dimen2 =3D .55pt % Thickness of rules % The text. (`r' is open on the right, `e' somewhat less so on the left.= ) -\setbox0 =3D \hbox{\kern-.75pt \reducedsf error\kern-1.5pt} +\setbox0 =3D \hbox{\kern-.75pt \reducedsf \putworderror\kern-1.5pt} % \setbox\errorbox=3D\hbox to \dimen0{\hfil \hsize =3D \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 =3D0 } =20 -% @footnotestyle is meaningful for info output only. +% @footnotestyle is meaningful for Info output only. \let\footnotestyle=3D\comment =20 {\catcode `\@=3D11 @@ -8166,6 +8179,8 @@ % expands into a box, it must come within the paragraph, lest it % provide a place where TeX can split the footnote. \footstrut + % + % Invoke rest of plain TeX footnote routine. \futurelet\next\fo@t } }%end \catcode `\@=3D11 =3D=3D=3D 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 =20 #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \ - (((__GNUC__ >=3D 3 || __GNUG__ >=3D 2) && !__STRICT_ANSI__) \ + (((__GNUC__ >=3D 3 || __GNUG__ >=3D 2) && !defined __STRICT_ANSI__) \ /* || __STDC_VERSION__ >=3D 199901L */ ) =20 #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS =3D=3D=3D 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=3D. --lib=3Dlibgnu --source-b= ase=3Dlib --m4-base=3Dm4 --doc-base=3Ddoc --tests-base=3Dtests --aux-dir=3D= build-aux --avoid=3Dmsvc-inval --avoid=3Dmsvc-nothrow --avoid=3Dpathmax -= -avoid=3Draise --avoid=3Dthreadlib --makefile-name=3Dgnulib.mk --conditio= nal-dependencies --no-libtool --macro-prefix=3Dgl --no-vc-files alloca-op= t careadlinkat crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 dtoastr= dup2 filemode getloadavg getopt-gnu ignore-value intprops lstat mktime p= thread_sigmask readlink socklen stdarg stdio strftime strtoimax strtoumax= symlink sys_stat +# Reproduce by: gnulib-tool --import --dir=3D. --lib=3Dlibgnu --source-b= ase=3Dlib --m4-base=3Dm4 --doc-base=3Ddoc --tests-base=3Dtests --aux-dir=3D= build-aux --avoid=3Dmsvc-inval --avoid=3Dmsvc-nothrow --avoid=3Dpathmax -= -avoid=3Draise --avoid=3Dthreadlib --makefile-name=3Dgnulib.mk --conditio= nal-dependencies --no-libtool --macro-prefix=3Dgl --no-vc-files alloca-op= t 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 s= trtoumax symlink sys_stat =20 =20 MOSTLYCLEANFILES +=3D core *.stackdump @@ -421,6 +421,29 @@ =20 ## end gnulib module stat =20 +## begin gnulib module stdalign + +BUILT_SOURCES +=3D $(STDALIGN_H) + +# We need the following in order to create 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 +=3D stdalign.h stdalign.h-t + +EXTRA_DIST +=3D stdalign.in.h + +## end gnulib module stdalign + ## begin gnulib module stdarg =20 BUILT_SOURCES +=3D $(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_NONBLOC= KING)/g' \ -e 's/@''GNULIB_UNISTD_H_SIGPIPE''@/$(GNULIB_UNISTD_H_SIGPIPE)/g'= \ -e 's/@''GNULIB_UNLINK''@/$(GNULIB_UNLINK)/g' \ =3D=3D=3D 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 @@ =20 #include "md5.h" =20 -#include +#include +#include #include #include #include @@ -254,8 +255,7 @@ if (len >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha1.h" =20 -#include +#include +#include #include #include =20 @@ -241,8 +242,7 @@ if (len >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha256.h" =20 -#include +#include +#include #include #include =20 @@ -51,7 +52,7 @@ =20 /* 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 >=3D 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) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 64) { =3D=3D=3D 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 @@ =20 #include "sha512.h" =20 -#include +#include +#include #include #include =20 @@ -58,7 +59,7 @@ =20 /* 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 >=3D 128) { #if !_STRING_ARCH_unaligned -# define alignof(type) offsetof (struct { char c; type x; }, x) -# define UNALIGNED_P(p) (((size_t) p) % alignof (u64) !=3D 0) +# define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (u64) !=3D 0) if (UNALIGNED_P (buffer)) while (len > 128) { =3D=3D=3D 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 !=3D SIG_IGN) (*handler) (SIGPIPE); } + return 0; } #endif =3D=3D=3D 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 . + + 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 Foundatio= n, + 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 for platforms that lack it. + + References: + ISO C1X + sections 6.5.3.4, 6.7.5, 7.15. + C++0X + 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 +#if defined __cplusplus + template struct __alignof_helper { char __a; __t __b; }; +# define _Alignof(type) offsetof (__alignof_helper, __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 <=3D __SUNPRO_C +# define _Alignas(a) __attribute__ ((__aligned__ (a))) +#elif 1300 <=3D _MSC_VER +# define _Alignas(a) __declspec (align (a)) +#endif +#ifdef _Alignas +# define alignas _Alignas +# define __alignas_is_defined 1 +#endif + +#endif /* _GL_STDALIGN_H */ =3D=3D=3D 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 =20 +#if @GNULIB_POSIX_OPENPT@ +/* Return an FD open to the master side of a pseudo-terminal. Flags sho= uld + 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 =20 +#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) =3D=3D=3D 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 =3D 0; then - REPLACE_DUP2=3D1 + if test $HAVE_DUP2 =3D 1; then + REPLACE_DUP2=3D1 + fi fi ]) ]) =3D=3D=3D 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 to declare environ. + AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) + + AC_CHECK_HEADERS_ONCE([unistd.h]) + gt_CHECK_VAR_DECL( + [#if HAVE_UNISTD_H + #include + #endif + /* mingw, BeOS, Haiku declare environ in , not in . */ + #include + ], + [environ]) + if test $gt_cv_var_environ_declaration !=3D yes; then + HAVE_DECL_ENVIRON=3D0 + 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 =3D 1;]])], + [gt_cv_var=3Dno], + [gt_cv_var=3Dyes])]) + AC_MSG_RESULT([$gt_cv_var]) + if test $gt_cv_var =3D 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]) +]) =3D=3D=3D 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 =3D 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=3D1 fi ]) =20 =3D=3D=3D 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 =3D 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=3D1 fi +AC_SUBST([GNULIB_GL_UNISTD_H_GETOPT]) gl_MODULE_INDICATOR_FOR_TESTS([getopt-gnu]) gl_FUNC_GETOPT_POSIX if test $REPLACE_GETOPT =3D 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=3D1 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 =3D 0 || test $REPLACE_READLINK =3D 1; then func_gl_gnulib_m4code_stat fi - if test $ac_cv_func_strtoimax =3D no; then - func_gl_gnulib_m4code_verify - fi if test $ac_cv_func_strtoimax =3D no && test $ac_cv_type_long_long_int= =3D yes; then func_gl_gnulib_m4code_strtoll fi - if test $ac_cv_func_strtoumax =3D no; then + if test $ac_cv_func_strtoimax =3D no; then func_gl_gnulib_m4code_verify fi if test $ac_cv_func_strtoumax =3D no && test $ac_cv_type_unsigned_long= _long_int =3D yes; then func_gl_gnulib_m4code_strtoull fi + if test $ac_cv_func_strtoumax =3D no; then + func_gl_gnulib_m4code_verify + fi m4_pattern_allow([^gl_GNULIB_ENABLED_]) AM_CONDITIONAL([gl_GNULIB_ENABLED_dosname], [$gl_gnulib_enabled_dosnam= e]) 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 =3D=3D=3D 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 <=3D __GNUC__ || (__GNUC__ =3D=3D 2 && 8 <=3D __GNUC_MINOR__) \ || 0x5110 <=3D __SUNPRO_C) # define _Noreturn __attribute__ ((__noreturn__)) -# elif 1200 <=3D _MSC_VER +# elif defined _MSC_VER && 1200 <=3D _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn =3D=3D=3D 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=3D'[/\\]' ;; *) - gl_dirsep_regex=3D'/' + gl_dirsep_regex=3D'\/' ;; esac + dnl A sed expression that turns a string into a basic reg= ular + dnl expression, for use within "/.../". + gl_make_literal_regex_sed=3D's,[]$^\\.*/[],\\&,g' changequote([,]) - gl_absolute_header_sed=3D'\|'"${gl_dirsep_regex}"']m4_def= n([gl_HEADER_NAME])[|{ - s|.*"\(.*'"${gl_dirsep_regex}"']m4_defn([gl_HEADER_NA= ME])[\)".*|\1| + gl_header_literal_regex=3D`echo ']m4_defn([gl_HEADER_NAME= ])[' \ + | sed -e "$gl_make_literal_regex= _sed"` + gl_absolute_header_sed=3D"/${gl_dirsep_regex}${gl_header_= literal_regex}/"'{ + s/.*"\(.*'"${gl_dirsep_regex}${gl_header_literal_rege= x}"'\)".*/\1/ changequote(,)dnl s|^/[^/]|//&| changequote([,])dnl =3D=3D=3D 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 @@ =20 AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK], [ + AC_REQUIRE([gl_SIGNAL_H_DEFAULTS]) + AC_CHECK_FUNCS_ONCE([pthread_sigmask]) LIB_PTHREAD_SIGMASK=3D =20 =3D=3D=3D 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 if it is not supported. + +AC_DEFUN([gl_STDALIGN_H], +[ + AC_CHECK_HEADERS_ONCE([stdalign.h]) + + if test $ac_cv_header_stdalign_h =3D yes; then + STDALIGN_H=3D'' + else + STDALIGN_H=3D'stdalign.h' + fi + + AC_SUBST([STDALIGN_H]) + AM_CONDITIONAL([GL_GENERATE_STDALIGN_H], [test -n "$STDALIGN_H"]) +]) =3D=3D=3D 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 #endif - ]], [_Exit atoll canonicalize_file_name getloadavg getsubopt grantpt= mkdtemp - mkostemp mkostemps mkstemp mkstemps ptsname random_r initstat_r sran= dom_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 srando= m_r + strtod strtoll strtoull unlockpt unsetenv]) ]) =20 AC_DEFUN([gl_STDLIB_MODULE_INDICATOR], @@ -50,7 +50,9 @@ GNULIB_MKOSTEMPS=3D0; AC_SUBST([GNULIB_MKOSTEMPS]) GNULIB_MKSTEMP=3D0; AC_SUBST([GNULIB_MKSTEMP]) GNULIB_MKSTEMPS=3D0; AC_SUBST([GNULIB_MKSTEMPS]) + GNULIB_POSIX_OPENPT=3D0; AC_SUBST([GNULIB_POSIX_OPENPT]) GNULIB_PTSNAME=3D0; AC_SUBST([GNULIB_PTSNAME]) + GNULIB_PTSNAME_R=3D0; AC_SUBST([GNULIB_PTSNAME_R]) GNULIB_PUTENV=3D0; AC_SUBST([GNULIB_PUTENV]) GNULIB_RANDOM_R=3D0; AC_SUBST([GNULIB_RANDOM_R]) GNULIB_REALLOC_POSIX=3D0; AC_SUBST([GNULIB_REALLOC_POSIX]) @@ -76,7 +78,9 @@ HAVE_MKOSTEMPS=3D1; AC_SUBST([HAVE_MKOSTEMPS]) HAVE_MKSTEMP=3D1; AC_SUBST([HAVE_MKSTEMP]) HAVE_MKSTEMPS=3D1; AC_SUBST([HAVE_MKSTEMPS]) + HAVE_POSIX_OPENPT=3D1; AC_SUBST([HAVE_POSIX_OPENPT]) HAVE_PTSNAME=3D1; AC_SUBST([HAVE_PTSNAME]) + HAVE_PTSNAME_R=3D1; AC_SUBST([HAVE_PTSNAME_R]) HAVE_RANDOM_H=3D1; AC_SUBST([HAVE_RANDOM_H]) HAVE_RANDOM_R=3D1; AC_SUBST([HAVE_RANDOM_R]) HAVE_REALPATH=3D1; AC_SUBST([HAVE_REALPATH]) @@ -95,6 +99,7 @@ REPLACE_MALLOC=3D0; AC_SUBST([REPLACE_MALLOC]) REPLACE_MBTOWC=3D0; AC_SUBST([REPLACE_MBTOWC]) REPLACE_MKSTEMP=3D0; AC_SUBST([REPLACE_MKSTEMP]) + REPLACE_PTSNAME_R=3D0; AC_SUBST([REPLACE_PTSNAME_R]) REPLACE_PUTENV=3D0; AC_SUBST([REPLACE_PUTENV]) REPLACE_REALLOC=3D0; AC_SUBST([REPLACE_REALLOC]) REPLACE_REALPATH=3D0; AC_SUBST([REPLACE_REALPATH]) =3D=3D=3D 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=3D0; AC_SUBST([GNULIB_SYMLINK]) GNULIB_SYMLINKAT=3D0; AC_SUBST([GNULIB_SYMLINKAT]) GNULIB_TTYNAME_R=3D0; AC_SUBST([GNULIB_TTYNAME_R]) - GNULIB_UNISTD_H_GETOPT=3D0; AC_SUBST([GNULIB_UNISTD_H_GETOPT]) GNULIB_UNISTD_H_NONBLOCKING=3D0; AC_SUBST([GNULIB_UNISTD_H_NONBLOCKING= ]) GNULIB_UNISTD_H_SIGPIPE=3D0; AC_SUBST([GNULIB_UNISTD_H_SIGPIPE]) GNULIB_UNLINK=3D0; AC_SUBST([GNULIB_UNLINK]) From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#10155: OSX breakage Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 17:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Paul Eggert Cc: mario@lassnig.net, 9960@debbugs.gnu.org, cyd@gnu.org, 9772@debbugs.gnu.org, 10155@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132258796414603 (code B ref 9960); Tue, 29 Nov 2011 17:33:02 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 17:32:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVRXv-0003nP-B1 for submit@debbugs.gnu.org; Tue, 29 Nov 2011 12:32:43 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVRXn-0003mw-IV; Tue, 29 Nov 2011 12:32:36 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LVF00600LZ0JM00@a-mtaout20.012.net.il>; Tue, 29 Nov 2011 19:30:24 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.122.78]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVF005P5NAMASH0@a-mtaout20.012.net.il>; Tue, 29 Nov 2011 19:30:24 +0200 (IST) Date: Tue, 29 Nov 2011 19:30:30 +0200 From: Eli Zaretskii In-reply-to: <4ED50F3A.8040207@cs.ucla.edu> X-012-Sender: halo1@inter.net.il Message-id: <83k46i6dl5.fsf@gnu.org> References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Date: Tue, 29 Nov 2011 08:58:34 -0800 > From: Paul Eggert > CC: Chong Yidong , mario@lassnig.net, 9772@debbugs.gnu.org, > 9960@debbugs.gnu.org, 10155@debbugs.gnu.org, > Eli Zaretskii > > 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 to declare environ. > + AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) > + > + AC_CHECK_HEADERS_ONCE([unistd.h]) > + gt_CHECK_VAR_DECL( > + [#if HAVE_UNISTD_H > + #include > + #endif > + /* mingw, BeOS, Haiku declare environ in , not in . */ > + #include > + ], > + [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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#10155: OSX breakage Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2011 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mario@lassnig.net, 9960@debbugs.gnu.org, cyd@gnu.org, 9772@debbugs.gnu.org, 10155@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132259106719413 (code B ref 9960); Tue, 29 Nov 2011 18:25:02 +0000 Received: (at 9960) by debbugs.gnu.org; 29 Nov 2011 18:24:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVSLy-000530-MI for submit@debbugs.gnu.org; Tue, 29 Nov 2011 13:24:27 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVSLu-000523-OJ; Tue, 29 Nov 2011 13:24:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 7838DA6000B; Tue, 29 Nov 2011 10:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlj4orsUZX2d; Tue, 29 Nov 2011 10:22:20 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 172DDA60001; Tue, 29 Nov 2011 10:22:20 -0800 (PST) Message-ID: <4ED522DB.3080005@cs.ucla.edu> Date: Tue, 29 Nov 2011 10:22:19 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> In-Reply-To: <83k46i6dl5.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) 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.... From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: OSX breakage Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 02:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mario@lassnig.net, Paul Eggert , 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.1322620051303 (code B ref 9960); Wed, 30 Nov 2011 02:28:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 02:27:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVZtT-0008WQ-5b for submit@debbugs.gnu.org; Tue, 29 Nov 2011 21:27:31 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVZtQ-0008WB-Lf; Tue, 29 Nov 2011 21:27:29 -0500 Received: from [155.69.16.255] (port=16282 helo=furball) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RVZtN-0000pf-Gy; Tue, 29 Nov 2011 21:27:26 -0500 From: Chong Yidong References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <83obvu6fxf.fsf@gnu.org> Date: Wed, 30 Nov 2011 10:27:16 +0800 In-Reply-To: <83obvu6fxf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Nov 2011 18:39:56 +0200") Message-ID: <87d3cajqez.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#9772: bug#10155: OSX breakage Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 02:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Paul Eggert Cc: mario@lassnig.net, Eli Zaretskii , 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13226211591957 (code B ref 9960); Wed, 30 Nov 2011 02:46:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 02:45:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVaBL-0000VS-4I for submit@debbugs.gnu.org; Tue, 29 Nov 2011 21:45:59 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVaBH-0000V5-IQ; Tue, 29 Nov 2011 21:45:56 -0500 Received: from [155.69.16.255] (port=25824 helo=furball) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RVaBE-0001pr-LX; Tue, 29 Nov 2011 21:45:53 -0500 From: Chong Yidong References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> Date: Wed, 30 Nov 2011 10:45:42 +0800 In-Reply-To: <4ED522DB.3080005@cs.ucla.edu> (Paul Eggert's message of "Tue, 29 Nov 2011 10:22:19 -0800") Message-ID: <87sjl6iazt.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Paul Eggert 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++) { From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#9772: bug#10155: OSX breakage Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 04:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Chong Yidong Cc: mario@lassnig.net, eggert@cs.ucla.edu, 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13226259189014 (code B ref 9960); Wed, 30 Nov 2011 04:06:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 04:05:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVbQ4-0002LG-P0 for submit@debbugs.gnu.org; Tue, 29 Nov 2011 23:05:17 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVbPx-0002Ko-ME; Tue, 29 Nov 2011 23:05:11 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LVG00F00GMOI000@a-mtaout22.012.net.il>; Wed, 30 Nov 2011 06:04:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.185.72]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVG00FR7GO4FJ30@a-mtaout22.012.net.il>; Wed, 30 Nov 2011 06:04:53 +0200 (IST) Date: Wed, 30 Nov 2011 06:04:20 +0200 From: Eli Zaretskii In-reply-to: <87sjl6iazt.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83ehwq5k8r.fsf@gnu.org> References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> <87sjl6iazt.fsf@gnu.org> X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > From: Chong Yidong > Cc: Eli Zaretskii , mario@lassnig.net, 9960@debbugs.gnu.org, 9772@debbugs.gnu.org, 10155@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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#9772: bug#10155: OSX breakage Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 08:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mario@lassnig.net, eggert@cs.ucla.edu, 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132264089131062 (code B ref 9960); Wed, 30 Nov 2011 08:15:03 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 08:14:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVfJb-00084t-DM for submit@debbugs.gnu.org; Wed, 30 Nov 2011 03:14:51 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVfJX-00084S-3e; Wed, 30 Nov 2011 03:14:47 -0500 Received: from cm133.sigma4.maxonline.com.sg ([218.212.4.133]:32889 helo=furball) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RVfJS-0004W8-Ru; Wed, 30 Nov 2011 03:14:43 -0500 From: Chong Yidong References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> <87sjl6iazt.fsf@gnu.org> <83ehwq5k8r.fsf@gnu.org> Date: Wed, 30 Nov 2011 16:14:28 +0800 In-Reply-To: <83ehwq5k8r.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Nov 2011 06:04:20 +0200") Message-ID: <874nxm10yj.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Eli Zaretskii 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? From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#10155: bug#9772: bug#10155: OSX breakage Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 17:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Chong Yidong Cc: mario@lassnig.net, eggert@cs.ucla.edu, 9960@debbugs.gnu.org, 9772@debbugs.gnu.org, 10155@debbugs.gnu.org, Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267534521572 (code B ref 9960); Wed, 30 Nov 2011 17:50:01 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 17:49:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoHJ-0005bt-OK for submit@debbugs.gnu.org; Wed, 30 Nov 2011 12:49:05 -0500 Received: from mailout.melmac.se ([62.20.26.67]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoHB-0005ap-IZ for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 12:49:00 -0500 Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 5D504C8AC for <9960@debbugs.gnu.org>; Wed, 30 Nov 2011 18:48:51 +0100 (CET) Received: (qmail 5097 invoked by uid 89); 30 Nov 2011 16:48:39 -0000 Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 30 Nov 2011 16:48:39 -0000 Received: from anon-24-151.ipredate.net (unknown [93.182.151.24]) by coolsville.localdomain (Postfix) with ESMTPSA id 44CE57FA058; Wed, 30 Nov 2011 18:48:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jan =?UTF-8?Q?Dj=C3=A4rv?= In-Reply-To: <874nxm10yj.fsf@gnu.org> Date: Wed, 30 Nov 2011 18:48:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <36469E4B-8FD4-4371-A399-AD80B0E781EC@swipnet.se> References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> <87sjl6iazt.fsf@gnu.org> <83ehwq5k8r.fsf@gnu.org> <874nxm10yj.fsf@gnu.org> X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) 30 nov 2011 kl. 09:14 skrev Chong Yidong: > Eli Zaretskii 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC References: <8339e2lsu7.fsf@gnu.org> In-Reply-To: <8339e2lsu7.fsf@gnu.org> Resent-From: Tim Crews Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267542921698 (code B ref 9960); Wed, 30 Nov 2011 17:51:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 17:50:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoIe-0005du-0u for submit@debbugs.gnu.org; Wed, 30 Nov 2011 12:50:28 -0500 Received: from caiajhbdcagg.dreamhost.com ([208.97.132.66] helo=homiemail-a71.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVmP4-0002jG-Kz for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 10:49:00 -0500 Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 1E307428075 for <9960@debbugs.gnu.org>; Wed, 30 Nov 2011 07:48:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=code-affinity.com; h=message-id :date:from:mime-version:to:subject:content-type: content-transfer-encoding; q=dns; s=code-affinity.com; b=OjtXyg3 b+PgPUyk210pGUTafGJ+OPhn2PmjLW6C2YDEAYggWXKv6+lZYu+OIsPmIpGCHtKx VKeECyQQ0jUxQBJf+jB0l7LM4jN3HEqi2+RZ1lUP7wRrZ4DMoWB4rplOx9ITLC+x GKHfB7CQq0KBz0wtvNdqTRfG7EKvxXxLVgpU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=code-affinity.com; h= message-id:date:from:mime-version:to:subject:content-type: content-transfer-encoding; s=code-affinity.com; bh=XbJBk6ido2KWN AJR8hAeL7JRthM=; b=jc4Y+lI0S2MVhtiqtGcAgpMsRqrAYMTnza6Zb2pI2RHKh LmAXUX+yIpOSm3nLSSG/D2eWjTKkNG4qqneAphVP7mecmgtfeExYvLc+9f99CJ74 3Od8rfKO9muY1YNPzxfvL/zUWfA2ehAfFRiUuWEmXF9FofaDnMb0K4UIQAlFzQ= Received: from [192.168.1.100] (ip24-251-175-208.ph.ph.cox.net [24.251.175.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tim.crews@code-affinity.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id E59DA428072 for <9960@debbugs.gnu.org>; Wed, 30 Nov 2011 07:48:52 -0800 (PST) Message-ID: <4ED65062.8070607@code-affinity.com> Date: Wed, 30 Nov 2011 08:48:50 -0700 From: Tim Crews User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.1 (---) X-Mailman-Approved-At: Wed, 30 Nov 2011 12:50:26 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) In a (misguided) effort to debug the linum-mode problem that I reported yesterday (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.  The compilation of ntlib.c fails with

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\time.h(270) : error C2090: function returns array

I realize now that it was a waste of time to try to build an MSVC version of Emacs when the linum-mode bug was apparently caused by an issue with gcc.  But back on 11/27 you asked someone to try a MSVC build, so here you go.

Thank you for the work that you all do.

Tim Crews
From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Tim Crews Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267542921705 (code B ref 9960); Wed, 30 Nov 2011 17:51:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 17:50:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoIe-0005dw-SG for submit@debbugs.gnu.org; Wed, 30 Nov 2011 12:50:29 -0500 Received: from caiajhbdcahe.dreamhost.com ([208.97.132.74] helo=homiemail-a84.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVn2y-0003hf-72 for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 11:30:13 -0500 Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 54F7E1DE070 for <9960@debbugs.gnu.org>; Wed, 30 Nov 2011 08:30:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=code-affinity.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= code-affinity.com; b=sYa+etwDSi5DYpRwil3KXZ6/zwnpWA7mLgFcuU6Nw3V x9aPdyavkF1kUX1a/5NBspxf4n2N2wdmTPgzyqFLCSScSmOR+sYgxKs3hc92pwUw iy3kGKFobLmiq1ER+hbW/me06plqwAmOSHdbeCRHbTiXN4PVogS/aeuGx4SfEZmc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=code-affinity.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= code-affinity.com; bh=PU4uXAW5leFLxt952T/fIFOwTeQ=; b=zDJfUQQwJT 16sETgKTlZijglUGvRCK+Hm+G+5SAytzd0CE7eXHCfycpibYNVnqrIaeh2NpLRvn pftu2Ex8eqB4lW4b76+pvny1y74t5kbV0sPJKQeYyNR3FI5h85B4H2royC8Lfrqk 2AOE+hJYvPWQPj7wvelBmZwRAquHPpOQY= Received: from [192.168.1.100] (ip24-251-175-208.ph.ph.cox.net [24.251.175.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tim.crews@code-affinity.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 3637E1DE06A for <9960@debbugs.gnu.org>; Wed, 30 Nov 2011 08:30:07 -0800 (PST) Message-ID: <4ED65A0D.2000407@code-affinity.com> Date: Wed, 30 Nov 2011 09:30:05 -0700 From: Tim Crews User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED65062.8070607@code-affinity.com> In-Reply-To: <4ED65062.8070607@code-affinity.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Mailman-Approved-At: Wed, 30 Nov 2011 12:50:26 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) On 11/30/2011 8:48 AM, Tim Crews wrote:

The initial "nmake bootstrap" still does not work.  The compilation of ntlib.c fails with

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\time.h(270) : error C2090: function returns array

On further inspection, I see that Fabrice Popineau already posted a patch on 28 November that resolves this issue (Message 224).  This patch has not made it into the bzr source yet.

With Fabrice's patch in place, I am able to successfully build the 32-bit Windows Emacs with the MSVC toolchain.  I'm using it now.

Tim Crews
From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#9772: bug#10155: OSX breakage Resent-From: Mario Lassnig Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 17:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Chong Yidong Cc: Eli Zaretskii , eggert@cs.ucla.edu, 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155@debbugs.gnu.org Reply-To: mario@lassnig.net Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267547721803 (code B ref 9960); Wed, 30 Nov 2011 17:52:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 17:51:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoJQ-0005fa-A1 for submit@debbugs.gnu.org; Wed, 30 Nov 2011 12:51:17 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVi8D-0003lx-Ed; Wed, 30 Nov 2011 06:15:18 -0500 Received: by eabm6 with SMTP id m6so572227eab.3 for ; Wed, 30 Nov 2011 03:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1sVkLymGjilbix40GGEK9+q/6I4v7QmSDw6WT3jhGwo=; b=TaoyFsGyaqRFCiEY5BTkoF/NKaDZf+uFBPaBy+rI1vNmgTAh2iLJFrxy187PtYt287 LyccluNL6nVke6Ky4FcvJBa5uTbS7PYB7QwpsuBTKbF1Ofe1L4IdRnmWr+uaHlILsjQB JcRZ9ZzBdF7Np3448u1HWgISmU3pLRVxrZXH4= Received: by 10.180.74.141 with SMTP id t13mr1301004wiv.68.1322651713318; Wed, 30 Nov 2011 03:15:13 -0800 (PST) Received: from macatlas666.cern.ch (macatlas666.cern.ch. [137.138.205.22]) by mx.google.com with ESMTPS id dw6sm447088wib.12.2011.11.30.03.15.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Nov 2011 03:15:11 -0800 (PST) Message-ID: <4ED6103E.1030405@lassnig.net> Date: Wed, 30 Nov 2011 12:15:10 +0100 From: Mario Lassnig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> <87sjl6iazt.fsf@gnu.org> <83ehwq5k8r.fsf@gnu.org> <874nxm10yj.fsf@gnu.org> In-Reply-To: <874nxm10yj.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.6 (---) X-Mailman-Approved-At: Wed, 30 Nov 2011 12:51:13 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) On 11-11-30 9:14 , Chong Yidong wrote: > Eli Zaretskii 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@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@shodan:~/Development/emacs$ cd trunk/ Mario@shodan:~/Development/emacs/trunk$ echo $CFLAGS -march=core2 -msse4.1 Mario@shodan:~/Development/emacs/trunk$ echo $CC Mario@shodan:~/Development/emacs/trunk$ which gcc /usr/bin/gcc Mario@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@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@shodan:~/Development/emacs/trunk$ ./configure --with-ns 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Tim Crews Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267633623123 (code B ref 9960); Wed, 30 Nov 2011 18:06:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 18:05:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoXI-00060u-Dd for submit@debbugs.gnu.org; Wed, 30 Nov 2011 13:05:36 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVoXF-00060l-4K for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 13:05:34 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LVH00100JHTNK00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 20:05:27 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.234.164]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVH00GSGJL2YW02@a-mtaout20.012.net.il>; Wed, 30 Nov 2011 20:05:27 +0200 (IST) Date: Wed, 30 Nov 2011 20:04:19 +0200 From: Eli Zaretskii In-reply-to: <4ED65062.8070607@code-affinity.com> X-012-Sender: halo1@inter.net.il Message-id: <8339d55vx8.fsf@gnu.org> References: <8339e2lsu7.fsf@gnu.org> <4ED65062.8070607@code-affinity.com> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Wed, 30 Nov 2011 08:48:50 -0700 > From: Tim Crews > > > 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Tim Crews Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 18:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132267763925112 (code B ref 9960); Wed, 30 Nov 2011 18:28:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 18:27:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVosI-0006Ww-PU for submit@debbugs.gnu.org; Wed, 30 Nov 2011 13:27:19 -0500 Received: from caiajhbdcbef.dreamhost.com ([208.97.132.145] helo=homiemail-a66.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVosG-0006Wm-5w for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 13:27:17 -0500 Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 0D8F1350072; Wed, 30 Nov 2011 10:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=code-affinity.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= code-affinity.com; b=evE19bs9f/wQjZ0+5pJWgHqFPEtCSa/0YJOc2sp+U/6 P+z6Q9iB1UzTwjMs9WHYFK9cyWQlEuk4XZmPn5OsM0fkF+gbVrz7jOYpQaclJkLX jO74UwtOPtNM04Y3zm6hyrNJIfow6HP1458vWdN11fKNkl1LScsKvBOAb2vFzg9w = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=code-affinity.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= code-affinity.com; bh=4ImLt6EpzrD4RHDRotI8uZAUMhA=; b=Du+y8W+n/B X8MgQ5SNEudK1Qt9v5nT02PyeGQAPCxhrylUpV2cu+wIAzZVl4+o6i/nigKrH9h8 zy0QJATtajRtgDOMZY69i6+6c1EVndC4wFWn1AKWbKqlGC6RpJxq485qJlXgh9Fl 6lAedMfcapswq3641IdJSSv13mEJ5t5HI= Received: from [192.168.1.100] (ip24-251-175-208.ph.ph.cox.net [24.251.175.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tim.crews@code-affinity.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 39C093500B0; Wed, 30 Nov 2011 10:22:09 -0800 (PST) Message-ID: <4ED6744D.70508@code-affinity.com> Date: Wed, 30 Nov 2011 11:22:05 -0700 From: Tim Crews User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <8339e2lsu7.fsf@gnu.org> <4ED65062.8070607@code-affinity.com> <8339d55vx8.fsf@gnu.org> In-Reply-To: <8339d55vx8.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.4 (--) 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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 19:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Tim Crews Cc: 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132268074629854 (code B ref 9960); Wed, 30 Nov 2011 19:20:02 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 19:19:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVpgP-0007lT-Ht for submit@debbugs.gnu.org; Wed, 30 Nov 2011 14:19:06 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVpgN-0007l7-0J for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 14:19:04 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LVH00C00MVI4500@a-mtaout23.012.net.il> for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 21:18:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.141.228]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVH00BO0MZKSMC0@a-mtaout23.012.net.il>; Wed, 30 Nov 2011 21:18:56 +0200 (IST) Date: Wed, 30 Nov 2011 21:17:49 +0200 From: Eli Zaretskii In-reply-to: <4ED6744D.70508@code-affinity.com> X-012-Sender: halo1@inter.net.il Message-id: <83y5ux4dya.fsf@gnu.org> References: <8339e2lsu7.fsf@gnu.org> <4ED65062.8070607@code-affinity.com> <8339d55vx8.fsf@gnu.org> <4ED6744D.70508@code-affinity.com> X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.7 (-) > Date: Wed, 30 Nov 2011 11:22:05 -0700 > From: Tim Crews > Cc: 9960@debbugs.gnu.org > > > If you tried a 64-bit build, then it is not yet supported on Windows. > > Try the 32-bit build, it should work. > > I was doing a 32-bit build. There are still a few minor changes from > Fabrice Popineau that haven't made it into bzr yet. > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#224) With those > changes, the build succeeds. Which changes, specifically, are needed? I know only about one issue: the one with _tzname. The rest, to the best of my knowledge, are for a 64-bit build. If I'm wrong, I'd like to know which other changes are still needed for the 32-bit build with MSVC. > I built from the latest bzr source and can confirm that the linum-mode > crash no longer occurs on my end. Thanks. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Tim Crews Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2011 19:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132268214532002 (code B ref 9960); Wed, 30 Nov 2011 19:43:01 +0000 Received: (at 9960) by debbugs.gnu.org; 30 Nov 2011 19:42:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVq2y-0008K6-91 for submit@debbugs.gnu.org; Wed, 30 Nov 2011 14:42:25 -0500 Received: from caiajhbdcaib.dreamhost.com ([208.97.132.81] helo=homiemail-a74.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RVq2u-0008Jr-3c for 9960@debbugs.gnu.org; Wed, 30 Nov 2011 14:42:21 -0500 Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 0C77E67C07E; Wed, 30 Nov 2011 11:42:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=code-affinity.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= code-affinity.com; b=B8APWn7kHvyUhjL0hjzsyUljhr5GgiXkgNKlMeIg2hr m7rlCTYPj9Dcvl/Gb3VVUCN48yN1xQsVhetLtdf20fsPy3bEIOx2pFNLIVeykoAo /30pNJTjrOMuh5hLena0csY3smpR6o5+EhOLhbreZt6IopvXk6WAFbd7lzejJkiM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=code-affinity.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= code-affinity.com; bh=TdDZQ6Eq22BAxkM1VklNAaJ1T8M=; b=iXfeCmJTvw 0ktCUjf+LPHxScHsBcnFT/XmLq/+GbZWzWS9ELb8XwBKu18YJ5/UN5yikPvTiwpX wUTKBeexyzFzbAWaqLIuAuDHwq83L02wsQYVdPL81n4+rfPgZ6BZxEbkbxX44BgY oZvi2ZoHDzwcCiRLnW0fl0AggVZmkICYk= Received: from [192.168.1.100] (ip24-251-175-208.ph.ph.cox.net [24.251.175.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tim.crews@code-affinity.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id AECE967C07D; Wed, 30 Nov 2011 11:42:11 -0800 (PST) Message-ID: <4ED68710.5020304@code-affinity.com> Date: Wed, 30 Nov 2011 12:42:08 -0700 From: Tim Crews User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 References: <8339e2lsu7.fsf@gnu.org> <4ED65062.8070607@code-affinity.com> <8339d55vx8.fsf@gnu.org> <4ED6744D.70508@code-affinity.com> <83y5ux4dya.fsf@gnu.org> In-Reply-To: <83y5ux4dya.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.4 (--) On 11/30/2011 12:17 PM, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2011 11:22:05 -0700 >> From: Tim Crews >> Cc: 9960@debbugs.gnu.org >> >>> If you tried a 64-bit build, then it is not yet supported on Windows. >>> Try the 32-bit build, it should work. >> >> I was doing a 32-bit build. There are still a few minor changes from >> Fabrice Popineau that haven't made it into bzr yet. >> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9960#224) With those >> changes, the build succeeds. > > Which changes, specifically, are needed? I know only about one issue: > the one with _tzname. The rest, to the best of my knowledge, are for > a 64-bit build. If I'm wrong, I'd like to know which other changes > are still needed for the 32-bit build with MSVC. > >> I built from the latest bzr source and can confirm that the linum-mode >> crash no longer occurs on my end. > > Thanks. There are only two changes listed in but 9960 message 224, both related to _tzname. (The patch is repeated for reference at the bottom of this message.) The changes are to lib/strftime.c and src/s/ms-w32.h. If I back out Fabrice's proposed change to lib/strftime.c, the build succeeds through the compilation phase but fails to link because of unresolved external _tzname. If I back out Fabrice's proposed change to src/s/ms-w32.h, compilation of ntlib.c fails with "time.h(270) : error C2090: function returns array". So it appears that both changes are needed for the MSVC 32-bit build. Tim Crews === modified file 'lib/strftime.c' --- lib/strftime.c 2011-03-31 04:24:03 +0000 +++ lib/strftime.c 2011-11-28 15:38:55 +0000 @@ -36,9 +36,13 @@ #include #include +#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 From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: bug#9772: bug#10155: OSX breakage Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2011 16:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: mario@lassnig.net Cc: Eli Zaretskii , Chong Yidong , 9772@debbugs.gnu.org, 9960@debbugs.gnu.org, 10155-done@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132275599118704 (code B ref 9960); Thu, 01 Dec 2011 16:14:02 +0000 Received: (at 9960) by debbugs.gnu.org; 1 Dec 2011 16:13:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RW9G3-0004rY-7Q for submit@debbugs.gnu.org; Thu, 01 Dec 2011 11:13:11 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RW9G0-0004rD-9l; Thu, 01 Dec 2011 11:13:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 4619539E800B; Thu, 1 Dec 2011 08:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBmu9p49RyG0; Thu, 1 Dec 2011 08:12:57 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E6C1C39E8008; Thu, 1 Dec 2011 08:12:57 -0800 (PST) Message-ID: <4ED7A789.7070602@cs.ucla.edu> Date: Thu, 01 Dec 2011 08:12:57 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 References: <4ED3AA79.8060605@lassnig.net> <838vn06swa.fsf@gnu.org> <4ED3DA30.1050006@cs.ucla.edu> <871usrh69t.fsf@gnu.org> <4ED4A5BE.80008@cs.ucla.edu> <4ED50F3A.8040207@cs.ucla.edu> <83k46i6dl5.fsf@gnu.org> <4ED522DB.3080005@cs.ucla.edu> <87sjl6iazt.fsf@gnu.org> <83ehwq5k8r.fsf@gnu.org> <874nxm10yj.fsf@gnu.org> <4ED6103E.1030405@lassnig.net> In-Reply-To: <4ED6103E.1030405@lassnig.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Dec 2011 08:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, Juanma Barranquero , monnier@iro.umontreal.ca, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132298603111277 (code B ref 9960); Sun, 04 Dec 2011 08:08:02 +0000 Received: (at 9960) by debbugs.gnu.org; 4 Dec 2011 08:07:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RX76M-0002vq-Kq for submit@debbugs.gnu.org; Sun, 04 Dec 2011 03:07:11 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RX76K-0002vi-4c for 9960@debbugs.gnu.org; Sun, 04 Dec 2011 03:07:09 -0500 Received: by bkas6 with SMTP id s6so130812bka.3 for <9960@debbugs.gnu.org>; Sun, 04 Dec 2011 00:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=sInxMotT6LZD3JvWXt2IWDXW9si0FtWvmfItrNaZ0CE=; b=YX1259QOTPb3fBiQfhex9IJIuhqTAQ9gL9qeoKbvQRd9cQFGt85rGeFgTX0y+d6Qsy YxPL49kFfFBj0ubaaHZasPE3QBP6ZZqYdytPC3+K9pB95hEjTi256euifX3Fn/2KXBGu D4pCsUOJqSc/g0TxcOqOQGkx+7uJ2wK/6n1ks= Received: by 10.204.156.133 with SMTP id x5mr2187260bkw.87.1322986002260; Sun, 04 Dec 2011 00:06:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.192.209 with HTTP; Sun, 4 Dec 2011 00:06:21 -0800 (PST) In-Reply-To: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> From: Fabrice Popineau Date: Sun, 4 Dec 2011 09:06:21 +0100 X-Google-Sender-Auth: OCoOLBeGjBRnH1n1l58nlffzfN0 Message-ID: Content-Type: multipart/alternative; boundary=0015175902a6b522e204b33fae5b X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) --0015175902a6b522e204b33fae5b Content-Type: text/plain; charset=ISO-8859-1 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 --0015175902a6b522e204b33fae5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Emacs compiles, bootstraps itself and loads on w64.
The diffs are not so large, I need to review them before
sen= ding a patch, but they are mainly located in=A0
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=A0
so on).

Best regards,

Fabrice
--0015175902a6b522e204b33fae5b-- From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Dec 2011 05:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, lekktu@gmail.com, monnier@iro.umontreal.ca, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13230618982940 (code B ref 9960); Mon, 05 Dec 2011 05:12:01 +0000 Received: (at 9960) by debbugs.gnu.org; 5 Dec 2011 05:11:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RXQq1-0000lM-IF for submit@debbugs.gnu.org; Mon, 05 Dec 2011 00:11:38 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RXQpy-0000lB-55 for 9960@debbugs.gnu.org; Mon, 05 Dec 2011 00:11:35 -0500 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RXQpS-0003iA-L2; Mon, 05 Dec 2011 00:11:02 -0500 Date: Mon, 05 Dec 2011 00:11:02 -0500 Message-Id: From: Eli Zaretskii In-reply-to: (message from Fabrice Popineau on Sun, 4 Dec 2011 09:06:21 +0100) References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <83wrau9lqx.fsf@gnu.org> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Fabrice Popineau > Date: Sun, 4 Dec 2011 09:06:21 +0100 > Cc: Juanma Barranquero , monnier@iro.umontreal.ca, cschol2112@googlemail.com, > 9960@debbugs.gnu.org > > Emacs compiles, bootstraps itself and loads on w64. > The diffs are not so large, I need to review them before > sending a patch, but they are mainly located in > alloc.c/gmalloc.c/ralloc.c . > I guess now I will have to use it a little bit to see if it is > stable. I'll try to put binaries on web access later this week > if anybody wants to test (64 bits dll are needed too, zlib and > so on). Great, thanks. If you don't mind, I'd urge you to sign legal papers. That would greatly simplify accepting changes from you in the future. If you agree, please ask Stefan Monnier or Chong Yidong to send you the paperwork. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Mar 2012 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Fabrice Popineau Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.133259868030929 (code B ref 9960); Sat, 24 Mar 2012 14:18:01 +0000 Received: (at 9960) by debbugs.gnu.org; 24 Mar 2012 14:18:00 +0000 Received: from localhost ([127.0.0.1]:36994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBRn5-00082n-Hx for submit@debbugs.gnu.org; Sat, 24 Mar 2012 10:18:00 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:50687) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBRmp-00082P-PB for 9960@debbugs.gnu.org; Sat, 24 Mar 2012 10:17:58 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1E00G005QJJN00@a-mtaout22.012.net.il> for 9960@debbugs.gnu.org; Sat, 24 Mar 2012 15:46:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.240.24]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1E00F4O68XU9F0@a-mtaout22.012.net.il>; Sat, 24 Mar 2012 15:46:11 +0200 (IST) Date: Sat, 24 Mar 2012 15:46:09 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83limqt8m6.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Fabrice Popineau > Date: Mon, 28 Nov 2011 20:07:29 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > On my side, there is still this messy 'tzname', which seems to be defined > in some part an not in some others. > I need the patch below. It could probably be eliminated by a careful > analysis of what files are included. > I think the problem is that tzname may be defined to be _tzname _before_ > including the regular MS . 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. From unknown Sat Jun 21 03:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#9960: Compiling Emacs trunk with MSVC Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Mar 2012 16:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.133260731914329 (code B ref 9960); Sat, 24 Mar 2012 16:42:02 +0000 Received: (at 9960) by debbugs.gnu.org; 24 Mar 2012 16:41:59 +0000 Received: from localhost ([127.0.0.1]:37075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBU2Q-0003j1-Ve for submit@debbugs.gnu.org; Sat, 24 Mar 2012 12:41:59 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:39920) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBU25-0003iX-VR for 9960@debbugs.gnu.org; Sat, 24 Mar 2012 12:41:57 -0400 Received: by bkuw5 with SMTP id w5so3083502bku.3 for <9960@debbugs.gnu.org>; Sat, 24 Mar 2012 09:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=TqED2VNvRHDfs87ZriYDL0NEL34ZROwa6/sFJAfpOxI=; b=ycVxwv2xSsjCbv6H0Rm5pxjesq/iduYMpWW1mhdjENkpRpPhRU+PtrP9K57aeTpVs4 2ui8P7lLlLX+sPsKE2nWWWDe5Ac6k6UVxyhobyW+sWewD5Qzx0dpWImbPMcptznx2Oj8 HOy+F7mZSlDfHtDGluaOq19nQ+YeLoFsVbkYQ5v/LJh5wgtMy+GZZEwcuDiXjOiHFh4L 8XUSppUzINDMB6l4xWUdThTgLSoQQnlEWc3rfxvo8DolvbUu0ipz+A9lhp26EFfdrNFs nG2OZoq+SjnwtQjblZMgRnzPSqsVvTOMrYbmmLBLOw8ndQ+veCAp9LKQC3I1CJhFvh72 9ZWw== Received: by 10.205.122.144 with SMTP id gg16mr6489173bkc.12.1332605437929; Sat, 24 Mar 2012 09:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.179.143 with HTTP; Sat, 24 Mar 2012 09:10:16 -0700 (PDT) In-Reply-To: <83limqt8m6.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> <83limqt8m6.fsf@gnu.org> From: Fabrice Popineau Date: Sat, 24 Mar 2012 17:10:16 +0100 X-Google-Sender-Auth: 1uGbJxS7bDe64DeEbVKz8EpTHK0 Message-ID: Content-Type: multipart/alternative; boundary=000e0ce004b4c0ea0904bbff61e0 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --000e0ce004b4c0ea0904bbff61e0 Content-Type: text/plain; charset=ISO-8859-1 > > > 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 . > > 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 --000e0ce004b4c0ea0904bbff61e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> On my side, there is still this messy 'tzname', which seems t= o be defined
> in some part an not in some others.
> I need the patch below. =A0It could probably be eliminated by a carefu= l
> analysis of what files are included.
> I think the problem is that tzname may be defined to be _tzname _befor= e_
> 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. =A0If no problems remain, I will close
this bug.


It is working out of the box.
I did a bootstrap after configure.bat.=A0
All I had to do was t= o set usercflags (graphics libraries and so on).

Thanks,

Fabrice

--000e0ce004b4c0ea0904bbff61e0-- From unknown Sat Jun 21 03:31:29 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#9960: closed (Re: bug#9960: Compiling Emacs trunk with MSVC) Message-ID: References: <83bonlu9gy.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> X-Gnu-PR-Message: they-closed 9960 X-Gnu-PR-Package: emacs,w32 Reply-To: 9960@debbugs.gnu.org Date: Sat, 24 Mar 2012 19:14:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1332616442-28473-1" This is a multi-part message in MIME format... ------------=_1332616442-28473-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #9960: Compiling Emacs trunk with MSVC which was filed against the emacs,w32 package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 9960@debbugs.gnu.org. --=20 9960: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D9960 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1332616442-28473-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 9960-done) by debbugs.gnu.org; 24 Mar 2012 19:13:45 +0000 Received: from localhost ([127.0.0.1]:37195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBWPH-0007Ob-7z for submit@debbugs.gnu.org; Sat, 24 Mar 2012 15:13:45 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61478) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBWP0-0007OC-B9 for 9960-done@debbugs.gnu.org; Sat, 24 Mar 2012 15:13:41 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1E00I00JUCK600@a-mtaout22.012.net.il> for 9960-done@debbugs.gnu.org; Sat, 24 Mar 2012 20:42:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.240.24]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1E00I45JYLDS60@a-mtaout22.012.net.il>; Sat, 24 Mar 2012 20:42:21 +0200 (IST) Date: Sat, 24 Mar 2012 20:42:21 +0200 From: Eli Zaretskii Subject: Re: bug#9960: Compiling Emacs trunk with MSVC In-reply-to: X-012-Sender: halo1@inter.net.il To: Fabrice Popineau Message-id: <83bonlu9gy.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83fwh975eg.fsf@gnu.org> <83limqt8m6.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 9960-done Cc: cschol2112@googlemail.com, 9960-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Fabrice Popineau > Date: Sat, 24 Mar 2012 17:10:16 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > > On my side, there is still this messy 'tzname', which seems to be defined > > > in some part an not in some others. > > > I need the patch below. It could probably be eliminated by a careful > > > analysis of what files are included. > > > I think the problem is that tzname may be defined to be _tzname _before_ > > > including the regular MS . > > > > 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. ------------=_1332616442-28473-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Nov 2011 11:23:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeL8-0001fM-QS for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:23:11 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMeL5-0001fE-Fe for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMeIT-0005Lw-8N for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:20:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:32953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIT-0005Ls-6d for submit@debbugs.gnu.org; Sat, 05 Nov 2011 07:20:25 -0400 Received: from eggs.gnu.org ([140.186.70.92]:40003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIQ-0000Eb-FP for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMeIN-0005LP-FR for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:22 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:64032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMeIM-0005L4-Pq for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 07:20:19 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LU600100Q14FF00@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2011 13:20:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.70.69]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LU60013SQ5D9190@a-mtaout22.012.net.il>; Sat, 05 Nov 2011 13:20:03 +0200 (IST) Date: Sat, 05 Nov 2011 13:19:28 +0200 From: Eli Zaretskii Subject: Compiling Emacs trunk with MSVC In-reply-to: X-012-Sender: halo1@inter.net.il To: Fabrice Popineau Message-id: <8339e2lsu7.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) 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 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 + +#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 +#include +#include +#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 +#endif #include === 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 #include +#ifndef _MSC_VER #include +#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 ------------=_1332616442-28473-1--