From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
Date: Wed, 23 Oct 2002 03:10:35 -0400 [thread overview]
Message-ID: <E184Ff1-0007WC-00@fencepost.gnu.org> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]
Any ideas for what to do here?
------- Start of forwarded message -------
Envelope-to: emacs-pretest-bug@gnu.org
Delivery-date: Mon, 21 Oct 2002 13:43:36 -0400
X-Originating-IP: [207.46.137.206]
From: "Jay Finger" <jay_finger@hotmail.com>
To: emacs-pretest-bug@gnu.org
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 -------
next reply other threads:[~2002-10-23 7:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 7:10 Richard Stallman [this message]
2002-10-23 12:06 ` [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows] Juanma Barranquero
2002-10-23 16:19 ` Andrew Choi
2002-10-23 16:47 ` Juanma Barranquero
2002-10-23 16:43 ` Eli Zaretskii
2002-10-24 6:47 ` Juanma Barranquero
2002-10-25 7:51 ` Juanma Barranquero
2002-10-23 12:13 ` Juanma Barranquero
2002-10-28 5:57 ` Harald.Maier.BW
2002-10-28 17:52 ` Juanma Barranquero
-- strict thread matches above, loose matches on Subject: below --
2002-10-23 13:37 jasonr
2002-10-23 13:43 ` Juanma Barranquero
2002-10-23 16:41 ` Eli Zaretskii
2002-10-24 6:42 ` Juanma Barranquero
2002-10-24 7:13 ` Eli Zaretskii
2002-10-24 8:06 ` Juanma Barranquero
2002-10-24 9:35 ` Kim F. Storm
2002-10-24 8:40 ` Juanma Barranquero
2002-10-24 17:28 ` Eli Zaretskii
2002-10-23 13:44 jasonr
2002-10-24 8:25 jasonr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E184Ff1-0007WC-00@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).