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: Mon, 28 Nov 2011 20:07:29 +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> <83fwh975eg.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0ce02ace0c506f04b2d038e6 X-Trace: dough.gmane.org 1322507303 19037 80.91.229.12 (28 Nov 2011 19:08:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2011 19:08:23 +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 Mon Nov 28 20:08:18 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 1RV6Yn-00021i-PK for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Nov 2011 20:08:14 +0100 Original-Received: from localhost ([::1]:53695 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV6Ym-0005S4-HT for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Nov 2011 14:08:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV6Yi-0005RT-MM for bug-gnu-emacs@gnu.org; Mon, 28 Nov 2011 14:08:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RV6Yh-0006Gv-29 for bug-gnu-emacs@gnu.org; Mon, 28 Nov 2011 14:08:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RV6Yg-0006Gk-MS for bug-gnu-emacs@gnu.org; Mon, 28 Nov 2011 14:08:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RV6aX-00026v-RI for bug-gnu-emacs@gnu.org; Mon, 28 Nov 2011 14:10:01 -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: 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: Original-Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.13225073898092 (code B ref 9960); Mon, 28 Nov 2011 19:10:01 +0000 Original-Received: (at 9960) by debbugs.gnu.org; 28 Nov 2011 19:09:49 +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 1RV6aL-00026T-D8 for submit@debbugs.gnu.org; Mon, 28 Nov 2011 14:09:49 -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 1RV6aI-00026L-L5 for 9960@debbugs.gnu.org; Mon, 28 Nov 2011 14:09:48 -0500 Original-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= Original-Received: by 10.205.132.146 with SMTP id hu18mr46722551bkc.123.1322507270114; Mon, 28 Nov 2011 11:07:50 -0800 (PST) Original-Received: by 10.205.132.20 with HTTP; Mon, 28 Nov 2011 11:07:29 -0800 (PST) In-Reply-To: <83fwh975eg.fsf@gnu.org> X-Google-Sender-Auth: g04lPeztd2Zz1hTdumNdmwp94I8 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 28 Nov 2011 14:10:01 -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:54382 Archived-At: --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--