From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#9960: Compiling Emacs trunk with MSVC Date: Fri, 11 Nov 2011 20:28:21 +0100 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> <8339dvgfpv.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00032556075e5f4bbd04b17a8741 X-Trace: dough.gmane.org 1321039796 4093 80.91.229.12 (11 Nov 2011 19:29:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2011 19:29:56 +0000 (UTC) Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 11 20:29:51 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ROwnP-0007O7-DH for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 20:29:51 +0100 Original-Received: from localhost ([::1]:45463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROwnO-0008Pt-IW for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 14:29:50 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:40777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROwnK-0008Pm-Po for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 14:29:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROwnJ-00058Z-4B for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 14:29:46 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROwnI-00058T-Ve for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 14:29:45 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ROwna-0004Hc-Dl for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 14:30:02 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132103974916377 (code B ref 9960); Fri, 11 Nov 2011 19:30:02 +0000 Original-Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 19:29:09 +0000 Original-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 Original-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 Original-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= Original-Received: by 10.204.29.8 with SMTP id o8mr9299379bkc.48.1321039722137; Fri, 11 Nov 2011 11:28:42 -0800 (PST) Original-Received: by 10.204.120.6 with HTTP; Fri, 11 Nov 2011 11:28:21 -0800 (PST) In-Reply-To: <8339dvgfpv.fsf@gnu.org> X-Google-Sender-Auth: -E1pYoYHG0ngIDYHCzn62BYnuV0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 11 Nov 2011 14:30:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53815 Archived-At: --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--