emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Two problems in Emacs-21.2.91 on Windows]


From: Harald . Maier . BW
Subject: Re: address@hidden: Two problems in Emacs-21.2.91 on Windows]
Date: Mon, 28 Oct 2002 06:57:42 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.91 (i386-mingw-nt5.0.2195)

Richard Stallman <address@hidden> writes:

> Any ideas for what to do here?
>
> From: "Jay Finger" <address@hidden>
> 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,





reply via email to

[Prev in Thread] Current Thread [Next in Thread]