unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Harald.Maier.BW@t-online.de
Cc: emacs-devel@gnu.org, emacs-pretest-bug@gnu.org
Subject: Re: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
Date: Mon, 28 Oct 2002 06:57:42 +0100	[thread overview]
Message-ID: <uwuo314x5.fsf@myself.com> (raw)
In-Reply-To: E184Ff1-0007WC-00@fencepost.gnu.org


Richard Stallman <rms@gnu.org> writes:

> Any ideas for what to do here?
>
> From: "Jay Finger" <jay_finger@hotmail.com>
> Subject: Two problems in Emacs-21.2.91 on Windows
> 
> ...
>
> 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?

I activated your later approach and this works fine. Personally, I
would take that approach beacause this works with less pain. Here a
patch with that compiling and linking works fine with MSVC 7. This is
only tested with the current development sources.

Harald

Index: w32heap.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32heap.c,v
retrieving revision 1.21
diff -c -r1.21 w32heap.c
*** w32heap.c	1 Jan 2002 19:10:04 -0000	1.21
--- w32heap.c	27 Oct 2002 16:50:10 -0000
***************
*** 282,288 ****
      sbrk (need_to_alloc);
  }
  
! #if (_MSC_VER >= 1000 && !defined(USE_CRT_DLL))
  
  /* MSVC 4.2 invokes these functions from mainCRTStartup to initialize
     a heap via HeapCreate.  They are normally defined by the runtime,
--- 282,288 ----
      sbrk (need_to_alloc);
  }
  
! #if (_MSC_VER >= 1000 && _MSC_VER < 1300 && !defined(USE_CRT_DLL))
  
  /* MSVC 4.2 invokes these functions from mainCRTStartup to initialize
     a heap via HeapCreate.  They are normally defined by the runtime,

  parent reply	other threads:[~2002-10-28  5:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23  7:10 [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows] Richard Stallman
2002-10-23 12:06 ` 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 [this message]
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=uwuo314x5.fsf@myself.com \
    --to=harald.maier.bw@t-online.de \
    --cc=emacs-devel@gnu.org \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=maierh@myself.com \
    /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).