From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain Date: Thu, 14 Mar 2013 08:45:38 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b343a7c9f524b04d7ddb6c7 X-Trace: ger.gmane.org 1363247241 24724 80.91.229.3 (14 Mar 2013 07:47:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Mar 2013 07:47:21 +0000 (UTC) Cc: 13939@debbugs.gnu.org To: =?UTF-8?Q?=E6=9D=8E=E4=B8=81?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 14 08:47:42 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UG2su-00082X-RT for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Mar 2013 08:47:33 +0100 Original-Received: from localhost ([::1]:44047 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG2sY-00060y-BD for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Mar 2013 03:47:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG2sR-00060K-PF for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 03:47:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG2sI-0001t3-6o for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 03:47:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG2sI-0001su-3G for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 03:46:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UG2tO-0000FX-Fl for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 03:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Mar 2013 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13939-submit@debbugs.gnu.org id=B13939.1363247239909 (code B ref 13939); Thu, 14 Mar 2013 07:48:02 +0000 Original-Received: (at 13939) by debbugs.gnu.org; 14 Mar 2013 07:47:19 +0000 Original-Received: from localhost ([127.0.0.1]:52644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG2sf-0000Eb-CZ for submit@debbugs.gnu.org; Thu, 14 Mar 2013 03:47:18 -0400 Original-Received: from mail-ee0-f41.google.com ([74.125.83.41]:38803) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG2sc-0000EJ-4b for 13939@debbugs.gnu.org; Thu, 14 Mar 2013 03:47:15 -0400 Original-Received: by mail-ee0-f41.google.com with SMTP id c13so887154eek.0 for <13939@debbugs.gnu.org>; Thu, 14 Mar 2013 00:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=L0iOY8Imfhha59ioEo/jAS/ETsTi4ubVN1TrI4VO0Eg=; b=GQT42BTbXCT1InkR32qZ5N+Wc7fjtCISnEXSzm/cy8m6iEyivGCMeKC9kDlu9GlYMM OHl1HxlpMQ46MlAX0osHk7Zh4hy2Dhvspbke8a0s6VpI5E71BJmp0pj9EMDNRWj+XlyX I1NlzswfCGlZ+lBCdbHDVmmf+zSmpdvLh4r/+S45TlvI7KwVnl7zDPQhzHMjSEWfwZRR KBWNgzT6NaXb5GE+GFO84rDtshNblrMRUj3hrgTg+74ihPNnyj+xqaNV327/QrAKUh6K AymWsYmFAPoKBNzqkAWpPEm0dEk68b0NOD9WTpnbyDuk6sM0XNiFtfMaGdbX/CBQFbv4 dZBg== X-Received: by 10.14.207.73 with SMTP id m49mr4046062eeo.24.1363247158469; Thu, 14 Mar 2013 00:45:58 -0700 (PDT) Original-Received: by 10.14.1.7 with HTTP; Thu, 14 Mar 2013 00:45:38 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72452 Archived-At: --047d7b343a7c9f524b04d7ddb6c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Eli: in what ways 24.3 differs from the current trunk ? Well, I can browse the diffs but you may have an insight of what's going wrong. At first, I thought about the thing we fixed with TZ. But it does not seem to be the problem. Albeit this maybe a source of a potential crash. The fix is needed for windows, given the way environment is handled (if I remember correctly). At this moment, I can compile the current trunk and bootstrap it. But not 24.3 . Fabrice 2013/3/14 =E6=9D=8E=E4=B8=81 > Sorry about that. I guess no one tried to build Emacs with MSVC >> during the entire pretest period. Perhaps in the future you could do >> that, so that any such problems could be fixed in time. > > > I'd like to. > > Or maybe it should say >> !if $(USE_CRT_DLL) >> instead? > > > Yes, seems more appropriate. > > Not only MinGW, but I believe Fabrice (CC'ed) also builds Emacs with >> MSVC and uses GC_MARK_STACK. > > > Maybe the the bug is introduced after Emacs 24.2, which can be built and > dumped with GC_MARK_STACK. > > Regarding the GC_MARK_STACK, I want to provide a little more information: > the error occurred after the first Fgarbage_collect while loading > loadup.el, and some important functions are not marked and thus garbage > collected. As in alloc.c the `car' of a cons is set to `Vdead' when freed= , > I suppose this is where the "DEAD" comes from. > > > 2013/3/14 Eli Zaretskii > >> > Date: Wed, 13 Mar 2013 06:47:56 +0800 >> > From: =E6=9D=8E=E4=B8=81 >> > >> > The latest 24.3 release won't compile on Windows with Visual C++ 2010 >> sp1 >> > compiler (comes with windows sdk 7.1). There are two problems: >> >> Sorry about that. I guess no one tried to build Emacs with MSVC >> during the entire pretest period. Perhaps in the future you could do >> that, so that any such problems could be fixed in time. >> >> > 1. nmake.defs has a syntax error on line 119: `!if' should be `!ifdef' >> >> Or maybe it should say >> >> !if $(USE_CRT_DLL) >> >> instead? >> >> > 2. GC_MARK_STACK is 1 by default in config.nt, but this default is >> broken >> > with the msvc toolchain. When temacs started to dump, >> > it immediately exited with the message `Invalid function: "DEAD"'. Eli >> had >> > previously told me (in #12878) to see bug #13070, but it didn't solve >> the >> > problem. When I tried to change GC_MARK_STACK to 0, Emacs compiled >> fine. So >> > there must be something wrong about the GCPROS_NOOPS way of marking >> stack >> > under the vc compiler, maybe someone familiar with the garbage collect= or >> > can fix it. (MinGW gcc is ok with the default) >> >> Not only MinGW, but I believe Fabrice (CC'ed) also builds Emacs with >> MSVC and uses GC_MARK_STACK. Fabrice, can you please comment on this? >> > > --047d7b343a7c9f524b04d7ddb6c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Eli: in what ways 24.3 differs from= the current trunk ?=C2=A0
Well, I can browse the diffs but you m= ay have an insight of what's going wrong.

At first, I thought about the thing we fixed with TZ. But it does not see= m to be the problem.
Albeit this maybe a source of a potential crash. The fix is need= ed for windows, given
the way environment is handled (if I = remember correctly).
At this moment, =C2=A0I can compile th= e current trunk and bootstrap it. But not 24.3 .

Fabrice




2013/3/14 =E6=9D=8E=E4=B8=81 <iamliding@gmail.com>
Sorry about tha= t. =C2=A0I guess no one tried to build Emacs with MSVC
during t= he entire pretest period. =C2=A0Perhaps in the future you could do
that, so that= any such problems could be fixed in time.

I'd like to.

=
=C2=A0Or maybe = it should say
=C2=A0 !if $= (USE_CRT_DLL)
instead?=
=C2=A0
Yes, seems more appropriate.
=

Not only MinGW, but I believe Fabrice (CC'ed) also builds Emacs with<= br> MSVC and= uses GC_MARK_STACK.

Maybe the= the bug is introduced after Emacs 24.2, which can be built and dumped with= GC_MARK_STACK.

Regarding the GC_MARK_STACK, I want to provide a little= more information: the error=C2=A0occurred after the first Fgarbage_collect= while loading loadup.el, and some important functions are not marked and t= hus garbage collected. As in alloc.c the `car' of a cons is set to `Vde= ad' when freed, I suppose this is where the "DEAD" comes from= .


2013/3/14 Eli= Zaretskii <eliz@gnu.org>
> Date: Wed, 13 Mar 2013 06:47:56 +0800
> From: =E6=9D=8E=E4=B8=81 <iamliding@gmail.com>
>
> The latest 24.3 release won't compile on Windows with Visual C++ 2= 010 sp1
> compiler (comes with windows sdk 7.1). There are two problems:

Sorry about that. =C2=A0I guess no one tried to build Emacs with MSVC
during the entire pretest period. =C2=A0Perhaps in the future you could do<= br> that, so that any such problems could be fixed in time.

> 1. nmake.defs has a syntax error on line 119: `!if' should be `!if= def'

Or maybe it should say

=C2=A0 !if $(USE_CRT_DLL)

instead?

> 2. GC_MARK_STACK is 1 by default in config.nt, but this default is bro= ken
> with the msvc toolchain. =C2=A0When temacs started to dump,
> it immediately exited with the message `Invalid function: "DEAD&q= uot;'. Eli had
> previously told me (in #12878) to see bug #13070, but it didn't so= lve the
> problem. When I tried to change GC_MARK_STACK to 0, Emacs compiled fin= e. So
> there must be something wrong about the GCPROS_NOOPS way of marking st= ack
> under the vc compiler, maybe someone familiar with the garbage collect= or
> can fix it. (MinGW gcc is ok with the default)

Not only MinGW, but I believe Fabrice (CC'ed) also builds Emacs with MSVC and uses GC_MARK_STACK. =C2=A0Fabrice, can you please comment on this?=


--047d7b343a7c9f524b04d7ddb6c7--