[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
address@hidden: Two problems in Emacs-21.2.91 on Windows]
From: |
Richard Stallman |
Subject: |
address@hidden: Two problems in Emacs-21.2.91 on Windows] |
Date: |
Wed, 23 Oct 2002 03:10:35 -0400 |
Any ideas for what to do here?
------- Start of forwarded message -------
Envelope-to: address@hidden
Delivery-date: Mon, 21 Oct 2002 13:43:36 -0400
X-Originating-IP: [207.46.137.206]
From: "Jay Finger" <address@hidden>
To: address@hidden
Bcc:
Subject: Two problems in Emacs-21.2.91 on Windows
Date: Mon, 21 Oct 2002 17:43:14 +0000
X-OriginalArrivalTime: 21 Oct 2002 17:43:14.0779 (UTC)
FILETIME=[551402B0:01C27929]
X-Spam-Status: No, hits=0.6 required=5.0
tests=SPAM_PHRASE_00_01
version=2.41
X-Spam-Level:
[Forgive me if this is the wrong alias for posting pretest bugs; Ive been
idling on this alias for a long time and my archive it doesnt contain the
procedure any more. Id be happy for pointers about where to rtfm about
that.]
Ive found two unrelated problems: one when building with MSVC 7, the other
in the w32 code.
1) When building with MSVC 7:
A linker error comes up complaining about multiply defined symbols for
_heap_init and _heap_term. These are both defined in w32heap.c, apparently
to prevent the functions with that name in the CRT from initializing the
heap. In the MSVC 7 libc.lib there are a couple of additional symbols
defined in the object with these functions that cause that object to get
sucked in, whereas it didn't used to get included. Simply removing
libc.lib(heapinit.obj) from the library creates it's own problems as it
removes other symbols needed by the CRT.
I found two hacks that seem to work, but I don't really like either because
there are sure to be issues I don't understand:
Linking with the libc.lib from MSVC 6 works: it links, Emacs seems to work
fine (I haven't played with any features added since 21.1.1, what I've been
running). I don't like this, though, since it requires hacking the build
environment, and there may be dependencies between the compiler and libc.lib
that I'm unaware of. (You definitely need the V7 libc.lib if you want to
compile with the /GS option, which was invaluable for finding the stack
corruption described below).
The other hack that seems to work OK (it links and runs with caveats as
above), is to just remove the definitions of _heap_init and _heap_term from
w32heap.c. The comment above those says "They are normally defined by the
runtime, but we override them here so that the unnecessary HeapCreate call
is not performed." If it's just an extra heap that we're worried about,
this should be slightly wasteful but harmless. But maybe there is some
problem caused by having that heap initialized that the comment doesn't
record?
2) Bug in w32_term_init in w32term.c.
This function calls w32_defined_color to do lookups of colors "white" and
"black". It passes a pointer to a COLORDEF, but w32_term_init expects a
pointer to an XColor. Debug builds run fine, but on optimized builds you
get a stack corruption and Emacs fails before painting the first window. I
hacked this by pasting in the definition for XColor into w32term.c and
passing in one of those, but I figure somebody would want to actually move
that structure to a header. A function prototype wouldn't hurt either :-)
jay
_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp
------- End of forwarded message -------
- address@hidden: Two problems in Emacs-21.2.91 on Windows],
Richard Stallman <=
Re: address@hidden: Two problems in Emacs-21.2.91 on Windows], Juanma Barranquero, 2002/10/23
Re: address@hidden: Two problems in Emacs-21.2.91 on Windows], Harald . Maier . BW, 2002/10/28