Sorry for the long delay before replying. The problem and the solution you suggest are clear, but I'd like to > try to find a cleaner solution, if possible, one that doesn't require > so many #ifdef's. Can you think of some change in one or two places > that would resolve this? Can MSVC be forced in some way to use an > unsigned type for enumerations, for example? If not, since the > problem is only with a single enumeration, would it work to use > something like this: > > enum Lisp_Misc_Type > { > Lisp_Misc_Free = 0x5eab, > Lisp_Misc_Marker = 0x5eac, > Lisp_Misc_Intfwd = 0x5ead, > > etc.? Or maybe use 0x5eabU etc., with an explicitly unsigned value? > No, that doesn't work. And somehow, I'm glad that the compiler can't be fooled this way. After looking around and googling about this issue, the problem is trickier than what I thought at first. Even my first explanation may not be complete. Anyway, mixing enum and bit fields seems to be incompatible with portability. Either you need to step back and type bit fields with int or unsigned int (and loose typechecking) or you need to get around with macros taking care of using enum or unsigned ints depending on the compiler. > A few other issues with the rest of the patch: > > > -# define DECL_ALIGN(type, var) \ > > +# define DECL_ALIGN(type, var) \ > > type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var > > Is this just some inadvertent reformatting, or is there some deeper > problem here? > Only reformatting, sorry. I'm not even sure that I needed to define DECL_ALIGN for msvc, because I set an option on the command line to align everything. > > 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 > > Why did you comment out these commands? They are not supposed to be > invoked under nmake, only under GNU Make. > They are not invoked, but the problem is that they are not parsable. Nmake fails to read the makefile. > > - memset (bloc->new_data + old_size, 0, size - old_size); > > + memset ((char *) bloc->new_data + old_size, 0, size - old_size); > > Is this a real problem, or just a left-over from some attempt to debug > memory allocation problems, resolved by "-dynamicbase:no"? If this is > a real problem, can you tell what it is? MSVC can't/doesnt want to do arithmetic on void pointers. > > +#define fstat(a, b) sys_fstat(a, b) > > +#define stat(a, b) sys_stat(a, b) > > +#define utime sys_utime > > Why did you need to do this? What happens if you don't? > If I don't do it, I get linking errors : temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol __imp__stat referenced in function _sys_sigblock temacs2.lib(image.obj) : error LNK2001: unresolved external symbol __imp__stat temacs1.lib(dired.obj) : error LNK2001: unresolved external symbol __imp__stat temacs1.lib(lread.obj) : error LNK2001: unresolved external symbol __imp__stat temacs1.lib(w32.obj) : error LNK2001: unresolved external symbol __imp__stat temacs1.lib(fileio.obj) : error LNK2001: unresolved external symbol __imp__stat temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol _utime referenced in function _set_file_times There are these 2 lines in src/s/ms-w32.h : #if !defined (_MSC_VER) || (_MSC_VER < 1400) #define tzname _tzname #define utime _utime #endif If I raise the 1400 to a higher value to include my version of the compiler, the compiler reports an error message about : C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\time.h(270) : error C2090: function returns array because tzname is defined as an array and that triggers a conflict. Why would it be a problem to map thos three calls to their sys_ version ? Performance ? > - if (tmp && _access (tmp, D_OK) == 0) > > + if (tmp && sys_access (tmp, D_OK) == 0) > > What's wrong with calling _access from the MS runtime? _access doesn't know about D_OK. Worse, D_OK is defined, it hides the fact that _access doesn't know about it. But _access crashes with this value. Anyway, sys_access is defined, so why not using it ? > > - " --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. > > +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 > > +) > > Is there a less system-dependent way of doing this? E.g., is there an > environment variable to replace the path to SetEnv.cmd? You may have several versions of the SDK. I put these lines to stress the fact that people wanting to compile emacs with the MS SDK need to set it up. Also, iti is needed to set it up according to the debug/release mode. > Also, how to > set the /win7 switch portably, so that it works on non-Windows 7 > platforms as well? This /win7 switch is unnecessary. > For that matter, is it at all necessary to call > SetEnv.cmd, in addition to using appropriate compiler/linker switches? > > I guess so, yes, to find the compiler, the include files and the libraries. Also, note that to copile the whole thing, I need to run : nmake USE_CRT_DLL=1 My best wishes for 2011. Happy New Year. Fabrice