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
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10665 in the body.
You can then email your comments to 10665 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10665; Package
emacs.
(Mon, 30 Jan 2012 18:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 30 Jan 2012 18:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgement at that address.
Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.
Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':
The problem is in the generated ../emacs-24.0.93/src/makefile, which
has the following target and associated rule:
globals.h: gl-stamp
@cmd /c rem true
In an MinGW/MSYS bash shell, this rule invokes the MS Windows cmd.exe
command interpreter, which issues a prompt and then does not exit, thereby
halting the build. The output from make looks like this, at this point:
echo timestamp > gl-stamp
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
c:\emacs-24.0.93\src>
Entering "exit" at the prompt causes the Windows cmd.exe to exit
resulting in the make build resuming. (NOTE: a build of the candidate
release for Emacs 23.4 does not have the problem.)
It appears that the above rule for the target globals.h
is an error.
FYI, I invoked configure.bat like this
cmd /c "configure.bat --cflags -fno-omit-frame-pointer --cflags -IC:/usr/include"
within a MinGW/MSYS bash shell. It reported the following:
Checking for 'cp'...
Checking for 'rm'...
Checking whether 'gcc' is available...
Checking whether gcc requires '-mno-cygwin'...
Checking whether W32 API headers are too old...
c:\emacs-24.0.93\nt>gcc -fno-omit-frame-pointer -IC:/usr/include -c junk.c
Using 'gcc'
Checking for libpng...
...PNG header available, building with PNG support.
Checking for libgnutls...
...gnutls.h not found, building without TLS support.
Checking for jpeg-6b...
...JPEG header available, building with JPEG support.
Checking for libgif...
...GIF header available, building with GIF support.
Checking for tiff...
...TIFF header available, building with TIFF support.
Checking for libXpm...
...XPM header available, building with XPM support.
Generating makefiles
1 file(s) copied.
config.settings
gmake.defs
..\nt\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\admin\unidata\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\lib-src\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\lib\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\src\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\doc\emacs\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\doc\misc\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\doc\lispref\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\doc\lispintro\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\lisp\makefile.w32-in
1 file(s) copied.
config.settings
gmake.defs
..\leim\makefile.w32-in
1 file(s) copied.
Emacs successfully configured.
Run `make' to build, then run `make install' to install.
In ../emacs-24.0.93/src/makefile,
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
c:/emacs-24.0.93/etc/DEBUG.
In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
of 2012-01-30 on A5032619
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --cflags -fno-omit-frame-pointer
-IC:/usr/include'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<escape> x r e p o r t SPC e m SPC b SPC <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)
[Message part 2 (text/html, inline)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Mon, 30 Jan 2012 18:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>:
bug acknowledged by developer.
(Mon, 30 Jan 2012 18:59:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
> From: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
> Date: Mon, 30 Jan 2012 12:35:02 -0600
>
> The problem is in the generated ../emacs-24.0.93/src/makefile, which
> has the following target and associated rule:
>
> globals.h: gl-stamp
> @cmd /c rem true
>
> In an MinGW/MSYS bash shell, this rule invokes the MS Windows cmd.exe
> command interpreter, which issues a prompt and then does not exit, thereby
> halting the build. The output from make looks like this, at this point:
>
> echo timestamp > gl-stamp
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> c:\emacs-24.0.93\src>
This is a known issue with the MSYS Bash. That shell is not supported
by the Windows build of Emacs, for this very reason, see nt/INSTALL.
Just remove MSYS from your PATH, and you should be able to build EMacs
just fine. You don't need a Unixy shell.
I'm closing this bug report.
Thanks for reporting and digging into this.
Message #11 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
I did some further investigation and the problem is definitely NOT with the MSYS bash. When I build from a Windows command line, I see the exact same symptom. It turns out that the actual problem is with the MSYS GNU make. If, instead, I use the MinGW GNU make executable, called mingw32-make.exe, the problem disappears. (The MSYS GNU make is version 3.81 while the MinGW version is 3.82.)
By the way, the nt/INSTALL file is very out-of-date with its disparaging remarks toward the MSYS port of bash. The latest version is really quite good. I have used it extensively for quite some time without any issues. Indeed, I have used it together with the MSYS GNU make on a large software development project for over a year, utilizing a large number of makefiles making extensive use of GNU make features; all without encountering any issues with these tools, until I ran into the problem with the rule for the globals.h target.
Finally, my previous concern about the rule for the target globals.h in the ../emacs-24.0.93/src/makefile:
globals.h: gl-stamp
@cmd /c rem true
seems to be still valid. What is the point of a rule explicitly invoking the Windows command interpreter and passing it ONLY a comment line?
Regards,
Kevin
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, January 30, 2012 12:56 PM
To: Gallagher, Kevin
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
> From: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
> Date: Mon, 30 Jan 2012 12:35:02 -0600
>
> The problem is in the generated ../emacs-24.0.93/src/makefile, which
> has the following target and associated rule:
>
> globals.h: gl-stamp
> @cmd /c rem true
>
> In an MinGW/MSYS bash shell, this rule invokes the MS Windows cmd.exe
> command interpreter, which issues a prompt and then does not exit, thereby
> halting the build. The output from make looks like this, at this point:
>
> echo timestamp > gl-stamp
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> c:\emacs-24.0.93\src>
This is a known issue with the MSYS Bash. That shell is not supported
by the Windows build of Emacs, for this very reason, see nt/INSTALL.
Just remove MSYS from your PATH, and you should be able to build EMacs
just fine. You don't need a Unixy shell.
I'm closing this bug report.
Thanks for reporting and digging into this.
Message #12 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
> From: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
> CC: "10665-done <at> debbugs.gnu.org" <10665-done <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 14:58:37 -0600
>
> I did some further investigation and the problem is definitely NOT with the MSYS bash. When I build from a Windows command line, I see the exact same symptom. It turns out that the actual problem is with the MSYS GNU make. If, instead, I use the MinGW GNU make executable, called mingw32-make.exe, the problem disappears. (The MSYS GNU make is version 3.81 while the MinGW version is 3.82.)
It's not the version of Make that matters (I've built Emacs with a
MinGW Make 3.81 many times), it's probably the way the MSYS Make tries
to convert arguments that start with a slash to Windows style file
names (/d/foo/bar -> d:/foo/bar). Except that /c is not a file
name...
> By the way, the nt/INSTALL file is very out-of-date with its disparaging remarks toward the MSYS port of bash. The latest version is really quite good. I have used it extensively for quite some time without any issues.
If you tell which version is working well, I can update nt/INSTALL.
However, in general, it doesn't make much sense to use MSYS tools
(_any_ MSYS tools) for building a native Windows port of Emacs. MSYS
is for configuring and building software originated on Unix and GNU
systems using Posix configury and scripts. The native Windows build
of Emacs does not use Posix machinery, it uses Windows batch files and
Makefile's that don't require a Posix shell. So you are really using
MSYS outside of its intended purpose. I don't recommend that, even
though I successfully use MSYS to configure and build other packages,
which don't have Windows-specific build procedures.
> Finally, my previous concern about the rule for the target globals.h in the ../emacs-24.0.93/src/makefile:
>
> globals.h: gl-stamp
> @cmd /c rem true
>
> seems to be still valid. What is the point of a rule explicitly invoking the Windows command interpreter and passing it ONLY a comment line?
How else can you have a command that does nothing? The Posix
equivalent is
globals.h: gl-stamp; @true
Message #13 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
Here's the version of MSYS bash that I find to be excellent.
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.
As for a command in a rule which does nothing, this works:
globals.h: gl-stamp
@echo
OK, technically it outputs a linefeed to stdout, but that is harmless in this context and requires less overhead than the original. (Both bash and cmd.exe have an echo command and both recognize the "@" syntax at the start of a command.)
In the original syntax:
globals.h: gl-stamp
@cmd /c rem true
make passes the command line to a sub-shell in which the invocation of cmd creates a second nested sub-shell where the line "rem true" is interpreted as a batch file "remark" command.
Here's some additional information for nt/INSTALL.
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.)
2. When building in MSYS bash, the following syntax for invoking the configure script must be used:
cmd /c "configure.bat --cflags -fno-omit-frame-pointer"
or
cmd /c "configure.bat --cflags -IC:/extras/include --cflags -fno-omit-frame-pointer"
In other words, configure.bat MUST be included within the double quotes.
3. Whether building in the bash shell or the cmd.exe shell, when using the MinGW tool set, all -I options passed to configure.bat must use the "drive-letter:" syntax with FORWARD slashes in the path!
Message #14 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
> From: "Gallagher, Kevin" <Kevin.Gallagher <at> boeing.com>
> CC: "10665-done <at> debbugs.gnu.org" <10665-done <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 19:12:27 -0600
>
> Here's the version of MSYS bash that I find to be excellent.
>
> GNU bash, version 3.1.17(1)-release (i686-pc-msys)
> Copyright (C) 2005 Free Software Foundation, Inc.
OK, I will add this. Thanks.
> As for a command in a rule which does nothing, this works:
>
> globals.h: gl-stamp
> @echo
>
> OK, technically it outputs a linefeed to stdout, but that is harmless in this context and requires less overhead than the original. (Both bash and cmd.exe have an echo command and both recognize the "@" syntax at the start of a command.)
It's true that both bash and cmd support @echo, but in cmd just
"@echo" will produce "ECHO is on.", not an empty line. The trick with
"rem" and the invocation through "cmd /c" are to countermand that,
because we need a Makefile that will work both when Bash is the shell
and when cmd is the shell.
> In the original syntax:
>
> globals.h: gl-stamp
> @cmd /c rem true
>
> make passes the command line to a sub-shell in which the invocation of cmd creates a second nested sub-shell where the line "rem true" is interpreted as a batch file "remark" command.
"Rem" is not just a batch file command, it is a first-class command in
cmd. You can type it from the command line, for example.
> Here's some additional information for nt/INSTALL.
>
> 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.
> 2. When building in MSYS bash, the following syntax for invoking the configure script must be used:
>
> cmd /c "configure.bat --cflags -fno-omit-frame-pointer"
>
> or
>
> cmd /c "configure.bat --cflags -IC:/extras/include --cflags -fno-omit-frame-pointer"
>
> In other words, configure.bat MUST be included within the double quotes.
>
> 3. Whether building in the bash shell or the cmd.exe shell, when using the MinGW tool set, all -I options passed to configure.bat must use the "drive-letter:" syntax with FORWARD slashes in the path!
This is already mentioned, thanks.
Message #15 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
I have some additional information.
At the end of the execution of the gl-stamp target, the following line is displayed:
cmd /c "fc /b gl-tmp globals.h >nul 2>&1 || cp -f gl-tmp globals.h"
The MSYS make doesn't have any problems with that line when executing within an MSYS bash shell. So I modified the globals.h target to look like this:
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".
>> Here's some additional information for nt/INSTALL.
>>
>> 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.
Message #16 received at 10665-done <at> debbugs.gnu.org (full text, mbox):
> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 29 Feb 2012 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 118 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.