From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Sat, 03 Mar 2012 09:58:10 +0200 Message-ID: <83fwdqazfx.fsf@gnu.org> References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <83ty2ltep0.fsf@gnu.org> <4F4EEBC2.5070704@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1330761537 11207 80.91.229.3 (3 Mar 2012 07:58:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2012 07:58:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 08:58:57 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S3jri-0004Zc-Dc for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2012 08:58:54 +0100 Original-Received: from localhost ([::1]:54777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3jrh-0003r8-T2 for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2012 02:58:53 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3jrA-0003lH-A1 for emacs-devel@gnu.org; Sat, 03 Mar 2012 02:58:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3jr8-0001aL-4Y for emacs-devel@gnu.org; Sat, 03 Mar 2012 02:58:19 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3jr7-0001a9-S2 for emacs-devel@gnu.org; Sat, 03 Mar 2012 02:58:18 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M0A00I00TZ2C600@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 03 Mar 2012 09:58:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.42.18]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0A00IYAU4Z1ZA0@a-mtaout22.012.net.il>; Sat, 03 Mar 2012 09:58:12 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148881 Archived-At: > From: Fabrice Popineau > Date: Thu, 1 Mar 2012 08:24:40 +0100 > Cc: Eli Zaretskii , ajmr@ilovetortilladepatatas.com, emacs-devel@gnu.org > > > /* Include before defining tzname, to avoid DLL clash. */ > > #include > > #define tzname _tzname > > [...] > The problem is trickier than this and probably need a careful > rewrite of ms-w32.h. In this file, names like tzname or fopen get > rewired. Some of them need to be rewired to sys_fopen or _fopen > (example) depending on whether it is for emacs or not. So a more > robust way of doing things would be to ensure that all system > headers are read once for all, then doing the rewiring for emacs and > for (not emacs). That should avoid the problem of tzname for > example. In the mean time, this is the smallest change I could come > with. What you propose didn't work (resulting in either : some > function returns an array, that is tzname, or _tzname being > undefined at link time). Can you show me the error messages, please, and perhaps also the relevant portions of the MS headers that trigger them? Including time.h before redefining tzname is exactly what you proposed (for system headers to be included before redefining), so I'm puzzled about what exactly went wrong in the case of tzname, and why what you suggest as a general method of fixing these problems didn't work in this particular case. > > > > #ifdef WINDOWSNT > > > > extern Lisp_Object w32_get_internal_run_time (void); > > > > + > > > > +extern struct tm *localtime (const time_t *t); > > > > #endif > > > > > > Why is this needed? It seems also unrelated to 64-bit Windows. > > Sure but the definition needs to be put somewhere because an int is > not the same size as a pointer in windows 64. But editfns.c includes "systime.h", which does this: #ifdef TIME_WITH_SYS_TIME #include #include #else #ifdef HAVE_SYS_TIME_H #include #else #include #endif #endif On Windows, ms-w32.h defines TIME_WITH_SYS_TIME to 1, so the above should have included the system header time.h, which I believe includes the prototype of localtime. So could you please look into this some more and find out why all this isn't working for you? TIA