> > 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