[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows 64 port
From: |
Eli Zaretskii |
Subject: |
Re: Windows 64 port |
Date: |
Sat, 10 Mar 2012 15:43:12 +0200 |
Ping! Fabrice, could you please respond?
I'd like to have the 32-bit MSVC compilation to work when Emacs 24.1
is released. So I need to resolve these issues and commit whatever
changes are needed for that.
TIA
> Date: Sat, 03 Mar 2012 09:58:10 +0200
> From: Eli Zaretskii <address@hidden>
> CC: address@hidden
>
> > From: Fabrice Popineau <address@hidden>
> > Date: Thu, 1 Mar 2012 08:24:40 +0100
> > Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden
> >
> > > /* Include <time.h> before defining tzname, to avoid DLL clash. */
> > > #include <time.h>
> > > #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 <sys/time.h>
> #include <time.h>
> #else
> #ifdef HAVE_SYS_TIME_H
> #include <sys/time.h>
> #else
> #include <time.h>
> #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
- Re: Windows 64 port, (continued)
- Re: Windows 64 port, Eli Zaretskii, 2012/03/01
- Re: Windows 64 port, Fabrice Popineau, 2012/03/01
- Re: Windows 64 port, Eli Zaretskii, 2012/03/02
- Re: Windows 64 port, Paul Eggert, 2012/03/02
- Re: Windows 64 port, Fabrice Popineau, 2012/03/02
- Re: Windows 64 port, Eli Zaretskii, 2012/03/02
- Re: Windows 64 port, Paul Eggert, 2012/03/03
- Re: Windows 64 port, Eli Zaretskii, 2012/03/03
- Re: Windows 64 port, Paul Eggert, 2012/03/04
Re: Windows 64 port, Eli Zaretskii, 2012/03/03
- Re: Windows 64 port,
Eli Zaretskii <=
Re: Windows 64 port, Fabrice Popineau, 2012/03/22
Re: Windows 64 port, Fabrice Popineau, 2012/03/22
Re: Windows 64 port, Fabrice Popineau, 2012/03/22
Re: Windows 64 port, Fabrice Popineau, 2012/03/22