From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Compiling (development) Emacs with MSVC Date: Mon, 3 Jan 2011 11:21:46 +0100 Message-ID: References: <83sjy5279e.fsf@gnu.org> <83oc8jfii1.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015174c0dfa2363a30498ee8604 X-Trace: dough.gmane.org 1294059298 1623 80.91.229.12 (3 Jan 2011 12:54:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 3 Jan 2011 12:54:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 03 13:54:53 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PZjw3-00012G-3h for ged-emacs-devel@m.gmane.org; Mon, 03 Jan 2011 13:54:53 +0100 Original-Received: from localhost ([127.0.0.1]:47324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZjw2-0003Fd-3f for ged-emacs-devel@m.gmane.org; Mon, 03 Jan 2011 07:54:50 -0500 Original-Received: from [140.186.70.92] (port=57737 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZhYJ-00028c-2u for emacs-devel@gnu.org; Mon, 03 Jan 2011 05:22:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZhYH-0001Kr-5q for emacs-devel@gnu.org; Mon, 03 Jan 2011 05:22:10 -0500 Original-Received: from mail-ew0-f41.google.com ([209.85.215.41]:35429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZhYG-0001Ke-Qt; Mon, 03 Jan 2011 05:22:09 -0500 Original-Received: by ewy27 with SMTP id 27so6838283ewy.0 for ; Mon, 03 Jan 2011 02:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=e5A3RcAuE+4Shtz8IwxUtPAC3RjwhagepzXLvZjTb2M=; b=KFXFVF4pq9KPTKR8w+wjOTpCHUu1zXJLUzdgyTLCRgCfQot+eU1ShGFHeZ56Oiyl3U OAXHTwSTTHd3vmYRoteJQC3v0Jy5ZEwFNxJyZ+wunSivBg7Kk/D1S3q3YWFRL2hUTDZT fIsYXiyjjJssRxnLUje58VTb5YlcYV2MNLRlo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=PAFEDAUPWWvg6MRqpuzcXCBxq9p0b+e4h/FlDFa6bymn2QIAkN5Uf/nTXBR0Rk9PI5 7mY4IByzLIfIOh8JOrewaEO1ZzaMgHXuj0+K0/PBJ9a+pXT2EmujyUxXVZaFNXF0Qvj2 uj6S0jiFSGYTYbVLgY9ji6N+gojTBaq4Zuu+M= Original-Received: by 10.213.4.209 with SMTP id 17mr6127135ebs.4.1294050126946; Mon, 03 Jan 2011 02:22:06 -0800 (PST) Original-Received: by 10.213.13.70 with HTTP; Mon, 3 Jan 2011 02:21:46 -0800 (PST) In-Reply-To: <83oc8jfii1.fsf@gnu.org> X-Google-Sender-Auth: N3n3-qgvenVqdLWF85z06HfmOpY X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Mon, 03 Jan 2011 07:54:43 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134206 Archived-At: --0015174c0dfa2363a30498ee8604 Content-Type: text/plain; charset=ISO-8859-1 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 --0015174c0dfa2363a30498ee8604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for the long delay before replying.

The problem and the solu= tion 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. =A0Can you think of some change in one or two places<= br> that would resolve this? =A0Can MSVC be forced in some way to use an
unsigned type for enumerations, for example? =A0If not, since the
problem is only with a single enumeration, would it work to use
something like this:

enum Lisp_Misc_Type
=A0{
=A0 =A0Lisp_Misc_Free =3D 0x5eab,
=A0 =A0Lisp_Misc_Marker =3D 0x5eac,
=A0 =A0Lisp_Misc_Intfwd =3D 0x5ead,

etc.? =A0Or maybe use 0x5eabU etc., with an explicitly unsigned value?
<= /blockquote>

No, that doesn't work. And somehow, I&#= 39;m glad that the compiler can't be fooled this way.
After l= ooking around and googling about this issue, the problem is trickier than w= hat I thought
at first. Even my first explanation may not be complete. Anyway, mixin= g enum and bit fields=A0
seems to be incompatible with portabilit= y. Either you need to step back and type bit fields=A0
with int o= r unsigned int (and loose typechecking) or =A0you need to get around with m= acros
taking care of using enum or unsigned ints depending on the compiler.<= /div>


=A0
A few other issues with the rest of the patch:

> -# =A0 define DECL_ALIGN(type, var) \
> +# =A0 define DECL_ALIGN(type, var) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> =A0 =A0 =A0 type __attribute__ ((__aligned__ (1 << GCTYPEBITS)))= var

Is this just some inadvertent reformatting, or is there some deeper
problem here?
=A0
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.

=A0
> =A0TAGS-gmake:
> - =A0 =A0 ../lib-src/$(BLD)/etags.exe --include=3DTAGS-LISP --include= =3D../nt/TAGS \
> - =A0 =A0 =A0 --regex=3D@../nt/emacs-src.tags \
> - =A0 =A0 =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> - =A0 =A0 ../lib-src/$(BLD)/etags.exe -a --regex=3D@../nt/emacs-src.ta= gs \
> - =A0 =A0 =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> - =A0 =A0 ../lib-src/$(BLD)/etags.exe -a --regex=3D@../nt/emacs-src.ta= gs \
> - =A0 =A0 =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> - =A0 =A0 =A0 $(CURDIR)/*.h
> +# ../lib-src/$(BLD)/etags.exe --include=3DTAGS-LISP --include=3D../nt= /TAGS \
> +# =A0 --regex=3D@../nt/emacs-src.tags \
> +# =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0))
> +# ../lib-src/$(BLD)/etags.exe -a --regex=3D@../nt/emacs-src.tags \ > +# =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1))
> +# ../lib-src/$(BLD)/etags.exe -a --regex=3D@../nt/emacs-src.tags \ > +# =A0 $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \
> +# =A0 $(CURDIR)/*.h

Why did you comment out these commands? =A0They 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. Nma= ke fails to read the makefile.

=A0
> - =A0 =A0 =A0 memset (bloc->new_data + old_size, 0, size - old_size= );
> + =A0 =A0 =A0 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"? =A0If = this is
a real problem, can you tell what it is?

MS= VC can't/doesnt want to do arithmetic on void pointers.
=A0= =A0
> +#define fstat(a, b) =A0 sys_fstat(a, b)
> +#define stat(a, b) =A0 sys_stat(a, b)
> +#define utime =A0 sys_utime

Why did you need to do this? =A0What happens if you don't?

If I don't do it, I get linking errors :
<= div>temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol __i= mp__stat=A0referenced in function _sys_sigblock
temacs2.lib(image.obj) : error LNK2001: unresolved external symbol __i= mp__stat
temacs1.lib(dired.obj) : error LNK2001: unresolved exter= nal symbol __imp__stat
temacs1.lib(lread.obj) : error LNK2001: un= resolved external symbol __imp__stat
temacs1.lib(w32.obj) : error LNK2001: unresolved external symbol __imp= __stat
temacs1.lib(fileio.obj) : error LNK2001: unresolved extern= al symbol __imp__stat
temacs2.lib(sysdep.obj) : error LNK2019: un= resolved external symbol _utime referenced in function _set_file_times=A0

There are these 2 lines in src/s/ms-w32.h :
<= div>
#if !defined (_MSC_VER) || (_MSC_VER < 1400)
#define tzname =A0 =A0_tzname
#define utime =A0_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)\Micros= oft Visual Studio 10.0\VC\INCLUDE\time.h(270) : error C2090: function retur= ns array

because tzname is defined as an array and that tr= iggers a conflict.

Why would it be a problem to ma= p thos three calls to their sys_ version ? Performance ?

> - =A0 =A0 =A0if (tmp && _access (tmp, D_OK) =3D=3D 0)
> + =A0 =A0 =A0if (tmp && sys_access (tmp, D_OK) =3D=3D 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 ?
=A0
=A0<= /blockquote>
> - =A0 =A0" --cflags", USER_CFLAGS,
> + =A0 =A0" --cflags", stringer(USER_CFLAGS),

Why did you need to stringify here? =A0USER_CFLAGS is supposed to be
defined to a quoted string, like " -DFOO". =A0Can you tell why th= is
didn't work for you?

Oops. I used this = hack long ago, and I reintroduced it. But my real problem is that user_cfla= gs contains
various -I<path> to find include files, and the= se paths have \ that are not doubled.
Stringifying is a bad idea and doesn't solve the problem at all. N= eed to find a better solution.

=A0=A0
> +rem set SDK environment
> +if (%noopt%) =3D=3D (Y) (
> + =A0 call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetE= nv.cmd" /x86 /win7 /Debug
> + =A0 set nodebug=3DN
> +)
> +
> +if (%nodebug%) =3D=3D (Y) (
> + =A0 call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetE= nv.cmd" /x86 /win7 /Release
> + =A0 set noopt=3DN
> +)

Is there a less system-dependent way of doing this? =A0E.g., is there an environment variable to replace the path to SetEnv.cmd? =A0

You may have several versions of the SDK. I put these line= s to stress the fact that people wanting
to compile emacs with th= e MS SDK need to set it up. Also, iti is needed to set it up according to t= he debug/release mode.
=A0=A0
Also, how to
set the /win7 switch portably, so that it works on non-Windows 7
platforms as well?

This /win7 switch is unn= ecessary.=A0
=A0
=A0For tha= t 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 t= hat to copile the whole thing, I need to run :

nmake USE_CRT_DLL=3D1

My best wishes for 2011.=A0<= /div>
Happy New Year.

Fabrice
--0015174c0dfa2363a30498ee8604--