GNU bug report logs - #9960
Compiling Emacs trunk with MSVC

Previous Next

Full log

Message #224 received at 9960 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: Re: bug#9960: Compiling Emacs trunk with MSVC
Date: Mon, 28 Nov 2011 20:07:29 +0100

[Message part 1 (text/plain, inline)]

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 <time.h> .

Greetings,

Fabrice


=== 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 <ctype.h>
 #include <time.h>

+#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
=== 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 <eliz <at> gnu.org>

> > From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
> > Date: Thu, 10 Nov 2011 20:56:11 +0100
> > Cc: cschol2112 <at> googlemail.com, 9960 <at> 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.
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.