GNU bug report logs - #10665
24.0.93; Building for MS Windows using MinGW encounters a build problem in ../emacs-24.0.93/src/makefile

Previous Next

Full log

Message #16 received at 10665-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
Cc: 10665-done <at> debbugs.gnu.org
Subject: Re: bug#10665: 24.0.93;
	Building for MS Windows using MinGW encounters a build problem
	in	../emacs-24.0.93/src/makefile
Date: Tue, 31 Jan 2012 18:31:02 +0200

> From: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
> CC: "10665-done <at> debbugs.gnu.org" <10665-done <at> debbugs.gnu.org>
> Date: Tue, 31 Jan 2012 10:08:51 -0600
> 
>     globals.h: gl-stamp
>           @cmd /c "rem true"
> 
> MSYS make now handles this correctly.  So, I suspect that the MSYS make issue is really not with the "/c" syntax, but rather with the embedded spaces found in the shell command line that follows "/c".

I will make that change, thanks.

> >> 1. When building on Windows XP, the option "-fno-omit-frame-pointer" must be used.
> >> Otherwise, entering a C-g will cause Emacs to crash.  
> >> NOTE:  It turns out that this is not necessary when building on Windows 7.
> >> (I don't have any information about other versions of Windows.)
> 
> > This is needed only with GCC 4.6.x, see etc/PROBLEMS.
> 
> As my note, above, indicates, this is NOT an issue with the identical MinGW port of GCC 4.6.x when building Emacs with it on the 64-bit version of Windows 7. So, I suspect that 32-bit version of Windows XP may share at least part or, perhaps, all the blame for this problem. 

No, it's a known bug in GCC.  That it only happens on 32-bit Windows
just means that the architecture differences wrt implementation of
setjmp/longjmp conspire to conceal the bug on 64-bit host.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.