bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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:

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

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 collector
can fix it. (MinGW gcc is ok with the default)

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> Date: Wed, 13 Mar 2013 06:47:56 +0800
> From: 李丁 <iamliding@gmail.com>
> 
> 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 collector
> 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?

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

>
> 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 <eliz@gnu.org>

> > Date: Wed, 13 Mar 2013 06:47:56 +0800
> > From: 李丁 <iamliding@gmail.com>
> >
> > 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 collector
> > 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?
>

[-- Attachment #2: Type: text/html, Size: 4230 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]

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 李丁 <iamliding@gmail.com>

> 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 <eliz@gnu.org>
>
>> > Date: Wed, 13 Mar 2013 06:47:56 +0800
>> > From: 李丁 <iamliding@gmail.com>
>> >
>> > 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 collector
>> > 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?
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5310 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

> 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 collector
> > 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?
>

I can confirm that with GC_MARK_STACK=0, 24.3 does compile with the MS
compiler.
With GC_MARK_STACK=1, 24.3 doesn't compile, but the current trunk (well, my
copy, but which is quite close) does compile, 32bits and 64bits.
It may be a bit hairy to find out why.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1597 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 14 Mar 2013 16:13:09 +0100
> Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
> 
> I can confirm that with GC_MARK_STACK=0, 24.3 does compile with the MS
> compiler.
> With GC_MARK_STACK=1, 24.3 doesn't compile, but the current trunk (well, my
> copy, but which is quite close) does compile, 32bits and 64bits.

Can you copy to 24.3 the changes made on trunk (in
editfns.c:set_time_zone_rule) to use putenv and unsetenv instead of
reallocating entries in 'environ', and see if that solves the problem
in 24.3?  In addition to the changes in editfns.c, you will also need
sys_putenv and unsetenv on w32.c.

TIA

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

I tried importing this change in editfns.c but it doesn't change anything.

If I run only temacs.exe without any arguments, I get a very quick
backtrace:

C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
Loading loadup.el (source)...
Invalid function: "DEAD"

> temacs.exe!eval_sub(__int64 form) Line 2195 C
  temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream, __int64
sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
start, __int64 end) Line 1845 C
  temacs.exe!Fload(__int64 file, __int64 noerror, __int64 nomessage,
__int64 nosuffix, __int64 must_suffix) Line 1326 C
  temacs.exe!eval_sub(__int64 form) Line 2161 C
  temacs.exe!Feval(__int64 form, __int64 lexical) Line 2006 C
  temacs.exe!internal_condition_case(__int64 (void) * bfun, __int64
handlers, __int64 (__int64) * hfun) Line 1290 C
  temacs.exe!top_level_1(__int64 ignore) Line 1190 C
  temacs.exe!internal_catch(__int64 tag, __int64 (__int64) * func, __int64
arg) Line 1060 C
  temacs.exe!command_loop() Line 1147 C
  temacs.exe!recursive_edit_1() Line 780 C
  temacs.exe!Frecursive_edit() Line 844 C
  temacs.exe!main(int argc, char * * argv) Line 1528 C

I put a breakpoint in xsignal1() to get this backtrace. So it seems that
eval() is unable to process any kind of function.

Fabrice




2013/3/14 Eli Zaretskii <eliz@gnu.org>

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Thu, 14 Mar 2013 16:13:09 +0100
> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
> >
> > I can confirm that with GC_MARK_STACK=0, 24.3 does compile with the MS
> > compiler.
> > With GC_MARK_STACK=1, 24.3 doesn't compile, but the current trunk (well,
> my
> > copy, but which is quite close) does compile, 32bits and 64bits.
>
> Can you copy to 24.3 the changes made on trunk (in
> editfns.c:set_time_zone_rule) to use putenv and unsetenv instead of
> reallocating entries in 'environ', and see if that solves the problem
> in 24.3?  In addition to the changes in editfns.c, you will also need
> sys_putenv and unsetenv on w32.c.
>
> TIA
>
>

[-- Attachment #2: Type: text/html, Size: 4169 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 14 Mar 2013 20:28:45 +0100
> Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
> 
> I tried importing this change in editfns.c but it doesn't change anything.
> 
> If I run only temacs.exe without any arguments, I get a very quick
> backtrace:
> 
> C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
> Loading loadup.el (source)...
> Invalid function: "DEAD"
> 
> > temacs.exe!eval_sub(__int64 form) Line 2195 C
>   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream, __int64
> sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
> start, __int64 end) Line 1845 C

Thanks.

李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
you build it as a 32-bit executable?

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
> you build it as a 32-bit executable?
>

I may add that I reported a 64bits stacktrace, but I get the exact same
result with 32bits:

> temacs.exe!xsignal1(int error_symbol, int arg) Line 1577 C
  temacs.exe!eval_sub(int form) Line 2193 C
  temacs.exe!readevalloop(int readcharfun, _iobuf * stream, int sourcename,
char printflag, int unibyte, int readfun, int start, int end) Line 1843 C
  temacs.exe!Fload(int file, int noerror, int nomessage, int nosuffix, int
must_suffix) Line 1317 C
  temacs.exe!eval_sub(int form) Line 2160 C
  temacs.exe!Feval(int form, int lexical) Line 2006 C
  temacs.exe!top_level_2() Line 1177 C
  temacs.exe!internal_condition_case(int (void) * bfun, int handlers, int
(int) * hfun) Line 1290 C
  temacs.exe!top_level_1(int ignore) Line 1190 C
  temacs.exe!internal_catch(int tag, int (int) * func, int arg) Line 1060 C
  temacs.exe!command_loop() Line 1147 C
  temacs.exe!recursive_edit_1() Line 779 C
  temacs.exe!Frecursive_edit() Line 844 C
  temacs.exe!main(int argc, char * * argv) Line 1528 C

I still wonder why the current trunk is working at all for me.

Fabrice

[-- Attachment #2: Type: text/html, Size: 3500 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

>
> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
> you build it as a 32-bit executable?


I compiled Emacs as a 32-bit executable.

If I run only temacs.exe without any arguments, I get a very quick
> backtrace:


I also traced the execution of `temacs -batch -l loadup dump' with windbg,
and got a similar stack trace as Fabrice (I breakpointed Fgarbage_collect):

temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @ 1843]
temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @ 1177]
temacs!internal_condition_case+0xde [d:\data\projects\emacs-24.3\src\eval.c
@ 1289]
temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @ 1185]
temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @ 1060]
temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @ 1146]
temacs!recursive_edit_1+0x71 [d:\data\projects\emacs-24.3\src\keyboard.c @
779]
temacs!Frecursive_edit+0x101 [d:\data\projects\emacs-24.3\src\keyboard.c @
844]
temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
temacs!__tmainCRTStartup+0x1bf
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
temacs!mainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c
@ 371]
temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]


When I stepped out Fgarbage_collect, the error occurred just after this gc
at here in eval_sub:

if (!CONSP (fun))
xsignal1 (Qinvalid_function, original_fun);

I also tried removing most of loadup.el, and temacs can execute only the
first few lines, and even an additional `(+ 1 1)' caused temacs to exit
with the "DEAD" message. As I previously reported, I guess that the first
garbage collection cycle does not mark any read-in form, thus all of them
are collected (and their car set to Vdead).


2013/3/15 Eli Zaretskii <eliz@gnu.org>

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Thu, 14 Mar 2013 20:28:45 +0100
> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
> >
> > I tried importing this change in editfns.c but it doesn't change
> anything.
> >
> > If I run only temacs.exe without any arguments, I get a very quick
> > backtrace:
> >
> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
> > Loading loadup.el (source)...
> > Invalid function: "DEAD"
> >
> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream, __int64
> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
> > start, __int64 end) Line 1845 C
>
> Thanks.
>
> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
> you build it as a 32-bit executable?
>

[-- Attachment #2: Type: text/html, Size: 6898 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 14 Mar 2013 22:06:37 +0100
> Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
> 
> > 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
> > you build it as a 32-bit executable?
> >
> 
> I may add that I reported a 64bits stacktrace, but I get the exact same
> result with 32bits:

For 64 bits, the trunk includes quite a few fixes that the emacs-24
branch doesn't.  But if you get the same crash in a 32-bit executable,
my theory that this is related to those fixes eats dust now.

If any one of you could debug this and find the culprit, we could fix
the emacs-24 branch.  Failing that, I suggest to use the trunk, in the
hope that the next release from that codebase will support MSVC.

Thanks.

> I still wonder why the current trunk is working at all for me.

Many things changed on the trunk, most of them unrelated.  Which one
is causing this, is hard to say.  One thing you can do is compare the
w32*.[ch] files and perhaps lisp.h as well, between these two
branches.  Not sure if it's worth your while, though, nor whether the
root cause will reveal itself this way.

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]

李丁:  could you try to compile the trunk with msvc and confirm that it is
working for you?
I would be very glad to hear a positive report, meaning I didn't mess
things up.

Fabrice


2013/3/15 李丁 <iamliding@gmail.com>

> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>> you build it as a 32-bit executable?
>
>
> I compiled Emacs as a 32-bit executable.
>
> If I run only temacs.exe without any arguments, I get a very quick
>> backtrace:
>
>
> I also traced the execution of `temacs -batch -l loadup dump' with windbg,
> and got a similar stack trace as Fabrice (I breakpointed Fgarbage_collect):
>
> temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
> temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
>  temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
> temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @ 1843]
> temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
> temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
> temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
> temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @ 1177]
> temacs!internal_condition_case+0xde
> [d:\data\projects\emacs-24.3\src\eval.c @ 1289]
> temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @ 1185]
> temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @ 1060]
> temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @
> 1146]
> temacs!recursive_edit_1+0x71 [d:\data\projects\emacs-24.3\src\keyboard.c @
> 779]
> temacs!Frecursive_edit+0x101 [d:\data\projects\emacs-24.3\src\keyboard.c @
> 844]
> temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
> temacs!__tmainCRTStartup+0x1bf
> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
> temacs!mainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c
> @ 371]
> temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]
>
>
> When I stepped out Fgarbage_collect, the error occurred just after this gc
> at here in eval_sub:
>
> if (!CONSP (fun))
> xsignal1 (Qinvalid_function, original_fun);
>
> I also tried removing most of loadup.el, and temacs can execute only the
> first few lines, and even an additional `(+ 1 1)' caused temacs to exit
> with the "DEAD" message. As I previously reported, I guess that the first
> garbage collection cycle does not mark any read-in form, thus all of them
> are collected (and their car set to Vdead).
>
>
> 2013/3/15 Eli Zaretskii <eliz@gnu.org>
>
>>  > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>> > Date: Thu, 14 Mar 2013 20:28:45 +0100
>> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
>> >
>> > I tried importing this change in editfns.c but it doesn't change
>> anything.
>> >
>> > If I run only temacs.exe without any arguments, I get a very quick
>> > backtrace:
>> >
>> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
>> > Loading loadup.el (source)...
>> > Invalid function: "DEAD"
>> >
>> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
>> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream, __int64
>> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
>> > start, __int64 end) Line 1845 C
>>
>> Thanks.
>>
>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>> you build it as a 32-bit executable?
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7809 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

Though there are some minor errors (easy to fix), the latest trunk compiles
fine with msvc.

2013/3/15 Fabrice Popineau <fabrice.popineau@gmail.com>

> 李丁:  could you try to compile the trunk with msvc and confirm that it is
> working for you?
> I would be very glad to hear a positive report, meaning I didn't mess
> things up.
>
> Fabrice
>
>
> 2013/3/15 李丁 <iamliding@gmail.com>
>
>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>> you build it as a 32-bit executable?
>>
>>
>> I compiled Emacs as a 32-bit executable.
>>
>> If I run only temacs.exe without any arguments, I get a very quick
>>> backtrace:
>>
>>
>> I also traced the execution of `temacs -batch -l loadup dump' with
>> windbg, and got a similar stack trace as Fabrice (I breakpointed
>> Fgarbage_collect):
>>
>> temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
>> temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
>>  temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
>> temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @ 1843]
>> temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
>> temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
>> temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
>> temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @
>> 1177]
>> temacs!internal_condition_case+0xde
>> [d:\data\projects\emacs-24.3\src\eval.c @ 1289]
>> temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @
>> 1185]
>> temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @ 1060]
>> temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @
>> 1146]
>> temacs!recursive_edit_1+0x71 [d:\data\projects\emacs-24.3\src\keyboard.c
>> @ 779]
>> temacs!Frecursive_edit+0x101 [d:\data\projects\emacs-24.3\src\keyboard.c
>> @ 844]
>> temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
>> temacs!__tmainCRTStartup+0x1bf
>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
>> temacs!mainCRTStartup+0xf
>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 371]
>> temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]
>>
>>
>> When I stepped out Fgarbage_collect, the error occurred just after this
>> gc at here in eval_sub:
>>
>> if (!CONSP (fun))
>> xsignal1 (Qinvalid_function, original_fun);
>>
>> I also tried removing most of loadup.el, and temacs can execute only the
>> first few lines, and even an additional `(+ 1 1)' caused temacs to exit
>> with the "DEAD" message. As I previously reported, I guess that the first
>> garbage collection cycle does not mark any read-in form, thus all of them
>> are collected (and their car set to Vdead).
>>
>>
>> 2013/3/15 Eli Zaretskii <eliz@gnu.org>
>>
>>>  > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>>> > Date: Thu, 14 Mar 2013 20:28:45 +0100
>>> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
>>> >
>>> > I tried importing this change in editfns.c but it doesn't change
>>> anything.
>>> >
>>> > If I run only temacs.exe without any arguments, I get a very quick
>>> > backtrace:
>>> >
>>> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
>>> > Loading loadup.el (source)...
>>> > Invalid function: "DEAD"
>>> >
>>> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
>>> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream, __int64
>>> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
>>> > start, __int64 end) Line 1845 C
>>>
>>> Thanks.
>>>
>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>> you build it as a 32-bit executable?
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 8621 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 4456 bytes --]

I guess this ends the hunt for what change fixed 24.3 for msvc.
I spent several hours trying to track it down, but couldn't. My closest
guest
is among the vector/list reading code. Lots of changes happened in this
area.
Nothing very obvious anyway.

It is very unlucky, because I compile the trunk quite often and this bug
never surfaced
for quite a long time (pre 24.1).

I guess the best option is to use the trunk as per Eli's proposal.

Fabrice


2013/3/15 李丁 <iamliding@gmail.com>

> Though there are some minor errors (easy to fix), the latest trunk
> compiles fine with msvc.
>
> 2013/3/15 Fabrice Popineau <fabrice.popineau@gmail.com>
>
>> 李丁:  could you try to compile the trunk with msvc and confirm that it is
>> working for you?
>> I would be very glad to hear a positive report, meaning I didn't mess
>> things up.
>>
>> Fabrice
>>
>>
>> 2013/3/15 李丁 <iamliding@gmail.com>
>>
>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>> you build it as a 32-bit executable?
>>>
>>>
>>> I compiled Emacs as a 32-bit executable.
>>>
>>> If I run only temacs.exe without any arguments, I get a very quick
>>>> backtrace:
>>>
>>>
>>> I also traced the execution of `temacs -batch -l loadup dump' with
>>> windbg, and got a similar stack trace as Fabrice (I breakpointed
>>> Fgarbage_collect):
>>>
>>> temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
>>> temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
>>>  temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
>>> temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @
>>> 1843]
>>> temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
>>> temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
>>> temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
>>> temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>> 1177]
>>> temacs!internal_condition_case+0xde
>>> [d:\data\projects\emacs-24.3\src\eval.c @ 1289]
>>> temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>> 1185]
>>> temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @
>>> 1060]
>>> temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>> 1146]
>>> temacs!recursive_edit_1+0x71 [d:\data\projects\emacs-24.3\src\keyboard.c
>>> @ 779]
>>> temacs!Frecursive_edit+0x101 [d:\data\projects\emacs-24.3\src\keyboard.c
>>> @ 844]
>>> temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
>>> temacs!__tmainCRTStartup+0x1bf
>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
>>> temacs!mainCRTStartup+0xf
>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 371]
>>> temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]
>>>
>>>
>>> When I stepped out Fgarbage_collect, the error occurred just after this
>>> gc at here in eval_sub:
>>>
>>> if (!CONSP (fun))
>>> xsignal1 (Qinvalid_function, original_fun);
>>>
>>> I also tried removing most of loadup.el, and temacs can execute only the
>>> first few lines, and even an additional `(+ 1 1)' caused temacs to exit
>>> with the "DEAD" message. As I previously reported, I guess that the first
>>> garbage collection cycle does not mark any read-in form, thus all of them
>>> are collected (and their car set to Vdead).
>>>
>>>
>>> 2013/3/15 Eli Zaretskii <eliz@gnu.org>
>>>
>>>>  > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>>>> > Date: Thu, 14 Mar 2013 20:28:45 +0100
>>>> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
>>>> >
>>>> > I tried importing this change in editfns.c but it doesn't change
>>>> anything.
>>>> >
>>>> > If I run only temacs.exe without any arguments, I get a very quick
>>>> > backtrace:
>>>> >
>>>> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
>>>> > Loading loadup.el (source)...
>>>> > Invalid function: "DEAD"
>>>> >
>>>> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
>>>> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream,
>>>> __int64
>>>> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
>>>> > start, __int64 end) Line 1845 C
>>>>
>>>> Thanks.
>>>>
>>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>> you build it as a 32-bit executable?
>>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 9720 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> Date: Fri, 15 Mar 2013 23:07:08 +0800
> From: 李丁 <iamliding@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 13939 <13939@debbugs.gnu.org>
> 
> Though there are some minor errors (easy to fix), the latest trunk compiles
> fine with msvc.

Thanks.  Could you please report those errors, so that we could fix
them in the repository?

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 15 Mar 2013 16:24:59 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 13939 <13939@debbugs.gnu.org>
> 
> I spent several hours trying to track it down, but couldn't. My closest
> guest
> is among the vector/list reading code. Lots of changes happened in this
> area.
> Nothing very obvious anyway.

Thank you for your efforts.

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 5045 bytes --]

Thinking about it, another option is to use GC_MARK_STACK = 0 . This way,
people can stick to 24.3 .

I'm a bit afraid of the unstable status of the trunk (strange things
happens sometimes, at the moment,
it seems that emacs keeps track of the size of my laptop, but gets it wrong
when I connect to an
external display. It keeps resizing frames to the wrong dimensions).

Fabrice


2013/3/15 Fabrice Popineau <fabrice.popineau@gmail.com>

> I guess this ends the hunt for what change fixed 24.3 for msvc.
> I spent several hours trying to track it down, but couldn't. My closest
> guest
> is among the vector/list reading code. Lots of changes happened in this
> area.
> Nothing very obvious anyway.
>
> It is very unlucky, because I compile the trunk quite often and this bug
> never surfaced
> for quite a long time (pre 24.1).
>
> I guess the best option is to use the trunk as per Eli's proposal.
>
> Fabrice
>
>
> 2013/3/15 李丁 <iamliding@gmail.com>
>
>> Though there are some minor errors (easy to fix), the latest trunk
>> compiles fine with msvc.
>>
>> 2013/3/15 Fabrice Popineau <fabrice.popineau@gmail.com>
>>
>>> 李丁:  could you try to compile the trunk with msvc and confirm that it
>>> is working for you?
>>> I would be very glad to hear a positive report, meaning I didn't mess
>>> things up.
>>>
>>> Fabrice
>>>
>>>
>>> 2013/3/15 李丁 <iamliding@gmail.com>
>>>
>>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>>> you build it as a 32-bit executable?
>>>>
>>>>
>>>> I compiled Emacs as a 32-bit executable.
>>>>
>>>> If I run only temacs.exe without any arguments, I get a very quick
>>>>> backtrace:
>>>>
>>>>
>>>> I also traced the execution of `temacs -batch -l loadup dump' with
>>>> windbg, and got a similar stack trace as Fabrice (I breakpointed
>>>> Fgarbage_collect):
>>>>
>>>> temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
>>>> temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
>>>>  temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
>>>> temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @
>>>> 1843]
>>>> temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
>>>> temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
>>>> temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
>>>> temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1177]
>>>> temacs!internal_condition_case+0xde
>>>> [d:\data\projects\emacs-24.3\src\eval.c @ 1289]
>>>> temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1185]
>>>> temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @
>>>> 1060]
>>>> temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1146]
>>>> temacs!recursive_edit_1+0x71
>>>> [d:\data\projects\emacs-24.3\src\keyboard.c @ 779]
>>>> temacs!Frecursive_edit+0x101
>>>> [d:\data\projects\emacs-24.3\src\keyboard.c @ 844]
>>>> temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
>>>> temacs!__tmainCRTStartup+0x1bf
>>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
>>>> temacs!mainCRTStartup+0xf
>>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 371]
>>>> temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]
>>>>
>>>>
>>>> When I stepped out Fgarbage_collect, the error occurred just after this
>>>> gc at here in eval_sub:
>>>>
>>>> if (!CONSP (fun))
>>>> xsignal1 (Qinvalid_function, original_fun);
>>>>
>>>> I also tried removing most of loadup.el, and temacs can execute only
>>>> the first few lines, and even an additional `(+ 1 1)' caused temacs to exit
>>>> with the "DEAD" message. As I previously reported, I guess that the first
>>>> garbage collection cycle does not mark any read-in form, thus all of them
>>>> are collected (and their car set to Vdead).
>>>>
>>>>
>>>> 2013/3/15 Eli Zaretskii <eliz@gnu.org>
>>>>
>>>>>  > From: Fabrice Popineau <fabrice.popineau@gmail.com>
>>>>> > Date: Thu, 14 Mar 2013 20:28:45 +0100
>>>>> > Cc: 李丁 <iamliding@gmail.com>, 13939 <13939@debbugs.gnu.org>
>>>>> >
>>>>> > I tried importing this change in editfns.c but it doesn't change
>>>>> anything.
>>>>> >
>>>>> > If I run only temacs.exe without any arguments, I get a very quick
>>>>> > backtrace:
>>>>> >
>>>>> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
>>>>> > Loading loadup.el (source)...
>>>>> > Invalid function: "DEAD"
>>>>> >
>>>>> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
>>>>> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream,
>>>>> __int64
>>>>> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
>>>>> > start, __int64 end) Line 1845 C
>>>>>
>>>>> Thanks.
>>>>>
>>>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>>> you build it as a 32-bit executable?
>>>>>
>>>>
>>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 10645 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Fri, 15 Mar 2013 20:49:22 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 13939 <13939@debbugs.gnu.org>
> 
> Thinking about it, another option is to use GC_MARK_STACK = 0 . This way,
> people can stick to 24.3 .

That's an alternative, yes.

> I'm a bit afraid of the unstable status of the trunk (strange things
> happens sometimes, at the moment,
> it seems that emacs keeps track of the size of my laptop, but gets it wrong
> when I connect to an
> external display. It keeps resizing frames to the wrong dimensions).

There was a bug which did that, but it was fixed yesterday.  Maybe you
should update your local trunk and rebuild.

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

>
> Thanks.  Could you please report those errors, so that we could fix
> them in the repository?


It seems that the `!if USE_CRT_DLL' thing is not fixed yet...

Line 79 of vm-limit.c references a not-defined macro UINTPTR_MAX.
I guess it should be UINTMAX_MAX after having a look at nt/stdint.h.




2013/3/15 Eli Zaretskii <eliz@gnu.org>

> > Date: Fri, 15 Mar 2013 23:07:08 +0800
> > From: 李丁 <iamliding@gmail.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 13939 <13939@debbugs.gnu.org>
> >
> > Though there are some minor errors (easy to fix), the latest trunk
> compiles
> > fine with msvc.
>
> Thanks.  Could you please report those errors, so that we could fix
> them in the repository?
>

[-- Attachment #2: Type: text/html, Size: 1631 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> Date: Sat, 16 Mar 2013 14:12:35 +0800
> From: 李丁 <iamliding@gmail.com>
> Cc: Fabrice Popineau <fabrice.popineau@gmail.com>, 13939 <13939@debbugs.gnu.org>
> 
> It seems that the `!if USE_CRT_DLL' thing is not fixed yet...

Fixed.

> Line 79 of vm-limit.c references a not-defined macro UINTPTR_MAX.
> I guess it should be UINTMAX_MAX after having a look at nt/stdint.h.

I added definition of UINTPTR_MAX to nt/stdint.h.

Committed as trunk revision 112056.

Please try the current trunk, these two problems should be fixed
there.

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

>
> Please try the current trunk, these two problems should be fixed
> there.


Now I can compile the latest trunk with msvc smoothly :)


2013/3/16 Eli Zaretskii <eliz@gnu.org>

> > Date: Sat, 16 Mar 2013 14:12:35 +0800
> > From: 李丁 <iamliding@gmail.com>
> > Cc: Fabrice Popineau <fabrice.popineau@gmail.com>, 13939 <
> 13939@debbugs.gnu.org>
> >
> > It seems that the `!if USE_CRT_DLL' thing is not fixed yet...
>
> Fixed.
>
> > Line 79 of vm-limit.c references a not-defined macro UINTPTR_MAX.
> > I guess it should be UINTMAX_MAX after having a look at nt/stdint.h.
>
> I added definition of UINTPTR_MAX to nt/stdint.h.
>
> Committed as trunk revision 112056.
>
> Please try the current trunk, these two problems should be fixed
> there.
>

[-- Attachment #2: Type: text/html, Size: 1629 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> Date: Sat, 16 Mar 2013 23:31:02 +0800
> From: 李丁 <iamliding@gmail.com>
> Cc: Fabrice Popineau <fabrice.popineau@gmail.com>, 13939 <13939@debbugs.gnu.org>
> 
> > Please try the current trunk, these two problems should be fixed
> > there.
> 
> 
> Now I can compile the latest trunk with msvc smoothly :)

Thanks.

So, unless one of you still wants to investigate what's wrong with
Emacs 24.3, I will close this bug report.

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[李丁]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

>
> So, unless one of you still wants to investigate what's wrong with

Emacs 24.3, I will close this bug report.


As for me, I think the problem can't be easily solved in a few days,
so you may close this bug report.


2013/3/16 Eli Zaretskii <eliz@gnu.org>

> > Date: Sat, 16 Mar 2013 23:31:02 +0800
> > From: 李丁 <iamliding@gmail.com>
> > Cc: Fabrice Popineau <fabrice.popineau@gmail.com>, 13939 <
> 13939@debbugs.gnu.org>
> >
> > > Please try the current trunk, these two problems should be fixed
> > > there.
> >
> >
> > Now I can compile the latest trunk with msvc smoothly :)
>
> Thanks.
>
> So, unless one of you still wants to investigate what's wrong with
> Emacs 24.3, I will close this bug report.
>

[-- Attachment #2: Type: text/html, Size: 1809 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

It is ok to close the bug for me too.

Fabrice


2013/3/17 李丁 <iamliding@gmail.com>

> So, unless one of you still wants to investigate what's wrong with
>
> Emacs 24.3, I will close this bug report.
>
>
> As for me, I think the problem can't be easily solved in a few days,
> so you may close this bug report.
>
>
> 2013/3/16 Eli Zaretskii <eliz@gnu.org>
>
>> > Date: Sat, 16 Mar 2013 23:31:02 +0800
>> > From: 李丁 <iamliding@gmail.com>
>> > Cc: Fabrice Popineau <fabrice.popineau@gmail.com>, 13939 <
>> 13939@debbugs.gnu.org>
>> >
>> > > Please try the current trunk, these two problems should be fixed
>> > > there.
>> >
>> >
>> > Now I can compile the latest trunk with msvc smoothly :)
>>
>> Thanks.
>>
>> So, unless one of you still wants to investigate what's wrong with
>> Emacs 24.3, I will close this bug report.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2331 bytes --]

bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 17 Mar 2013 09:43:59 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 13939 <13939@debbugs.gnu.org>
> 
> It is ok to close the bug for me too.

Closing.  Thanks to both of you for your help.