Building and Installing Emacs
- on Windows NT and Windows 95
+ on Windows NT/2K/XP and Windows 95/98/ME
-You need a compiler package to build and install Emacs on NT or Win95.
-If you don't have one, precompiled versions are available in
-ftp://ftp.cs.washington.edu/pub/ntemacs/<version>.
-
-Configuring:
-
-(1) In previous versions, you needed to edit makefile.def
- to reflect the compiler package that you are using. You should no
- longer have to do this if you have defined the INCLUDE and LIB
- environment variables, as is customary for use with Windows compilers.
- (Unless you are using MSVCNT 1.1, in which case you will need
- to set MSVCNT11 to be a non-zero value at the top of makefile.def.)
-
-(2) Choose the directory into which Emacs will be installed, and
- edit makefile.def to define INSTALL_DIR to be this directory.
- (Alternatively, if you have INSTALL_DIR set as an environment
- variable, the build process will ignore the value in makefile.def
- and use the value of the environment variable instead.) Note
- that if it is not installed in the directory in which it is built,
- the ~16 MB of lisp files will be copied into the installation directory.
-
- Also, makefile.def is sometimes unpacked read-only; use
-
- > attrib -r makefile.def
-
- to make it writable.
-
-(3) You may need to edit nt/paths.h to specify some other device
- instead of `C:'.
-
-Building:
-
-(4) The target to compile the sources is "all", and is recursive starting
- one directory up. The makefiles for the NT port are in files named
- "makefile.nt". To get things started, type in this directory:
-
- > nmake -f makefile.nt all
-
- or use the ebuild.bat file.
-
- When the files are compiled, you will see some warning messages declaring
- that some functions don't return a value, or that some data conversions
- will be lossy, etc. You can safely ignore these messages. The warnings
- may be fixed in the main FSF source at some point, but until then we
- will just live with them.
-
- NOTE: You should not have to edit src\paths.h to get Emacs to run
- correctly. All of the variables in src\paths.h are configured
- during start up using the nt\emacs.bat file (which gets installed
- as bin\emacs.bat -- see below).
-
-Installing:
-
-(5) Currently, Emacs requires a number of environment variables to be set
- for it to run correctly. A batch file, emacs.bat, is provided that
- sets these variables appropriately and then runs the executable
- (emacs.bat is generated using the definition of INSTALL_DIR in
- nt\makefile.def and the contents of nt\emacs.bat.in).
-
-(6) The install process will install the files necessary to run Emacs in
- INSTALL_DIR (which may be the directory in which it was built),
- and create a program manager/folder icon in a folder called GNU Emacs.
- From this directory, type:
-
- > nmake -f makefile.nt install
-
- or use the install.bat file.
-
-(7) Create the Emacs startup file. This file can be named either .emacs,
- as on Unix, or _emacs. Note that Emacs requires the environment
- variable HOME to be set in order for it to locate the startup file.
- HOME could be set, for example, in the System panel of the Control
- Panel on NT, or in autoexec.bat on Win95.
-
-(8) Start up Emacs.
-
- The installation process should have run the addpm.exe program, which
- does two things. First, it will create a set of registry keys that
- tell Emacs where to find its support files (lisp, info, etc.).
- Second, it will create a folder containing an icon linked to
- runemacs.exe (a wrapper program for invoking Emacs). You can
- also invoke addpm.exe by hand, giving the absolute directory name
- of the installation directory as the first argument:
-
- addpm.exe %INSTALL_DIR%
-
- Now, to run Emacs, simply click on the icon in the newly created
- folder or invoke runemacs.exe from a command prompt.
-
- Another alternative for running Emacs is to use the emacs.bat batch
- file in the bin directory (this was the traditional method of invoking
- Emacs). Edit the emacs.bat file to change the emacs_dir environment
- variable to point to the Emacs installation directory and invoke the
- emacs.bat file to run Emacs.
-
- Note that, on Win95, you are likely to get "Out of environment space"
- messages when invoking the emacs.bat batch file. The problem is that
- the console process in which the script is executed runs out of memory
- in which to set the Emacs environment variables. To get around this
- problem, create a shortcut icon to the emacs.bat script. Then right
- click on the icon and select Properties. In the dialog box that pops
- up, select the Memory tab and then change the Environment memory
- allocation from "Auto" to "1024". Close the dialog box and then
- double click on the icon to start Emacs.
-
-Debugging:
-
-(9) You should be able to debug Emacs using the MSVC debugger as you would
- any other program. To ensure that Emacs uses the lisp files associated
- with the source distribution that you are debugging, it is useful
- to set the Emacs environment variables to point Emacs to the
- source distribution. You can use the debug.bat batch file in this
- directory to setup the environment and invoke msdev on the
- emacs.exe executable.
-
- Emacs functions implemented in C use a naming convention that
- reflects their names in lisp. The names of the C routines are
- the lisp names prefixed with 'F', and with dashes converted to
- underscores. For example, the function call-process is implemented
- in C by Fcall_process. Similarly, lisp variables are prefixed
- with 'V', again with dashes converted to underscores. These
- conventions enable you to easily set breakpoints or examine familiar
- lisp variables by name.
-
- Since Emacs data is often in the form of a lisp object, and the
- Lisp_Object type is difficult to examine manually in the debugger,
- Emacs provides a helper routine called debug_print that prints out
- a readable representation of a Lisp_Object. The output from
- debug_print is sent to stderr, and to the debugger via the
- OutputDebugString routine. The output sent to stderr should be
- displayed in the console window that was opened when the emacs.exe
- executable was started. The output sent to the debugger should be
- displayed in its "Debug" output window.
-
- When you are in the process of debugging Emacs and you would like
- to examine the contents of a Lisp_Object variable, popup the
- QuickWatch window (QuickWatch has an eyeglass symbol on its button
- in the toolbar). In the text field at the top of the window, enter
- debug_print(<variable>) and hit return. For example, start
- and run Emacs in the debugger until it is waiting for user input.
- Then click on the Break button in the debugger to halt execution.
- Emacs should halt in ZwUserGetMessage waiting for an input event.
- Use the Call Stack window to select the procedure w32_msp_pump
- up the call stack (see below for why you have to do this). Open
- the QuickWatch window and enter debug_print(Vexec_path). Evaluating
- this expression will then print out the contents of the lisp
- variable exec-path.
-
- If QuickWatch reports that the symbol is unknown, then check the
- call stack in the Call Stack window. If the selected frame in the
- call stack is not an Emacs procedure, then the debugger won't
- recognize Emacs symbols. Instead, select a frame that is inside
- an Emacs procedure and try using debug_print again.
-
- If QuickWatch invokes debug_print but nothing happens, then check
- the thread that is selected in the debugger. If the selected
- thread is not the last thread to run (the "current" thread), then
- it cannot be used to execute debug_print. Use the Debug menu
- to select the current thread and try using debug_print again.
- Note that the debugger halts execution (e.g., due to a breakpoint)
- in the context of the current thread, so this should only be a problem
- if you've explicitly switched threads.
+ Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006
+ Free Software Foundation, Inc.
+ See the end of the file for copying permissions.
+
+* For the impatient
+
+ Here are the concise instructions for configuring and building the
+ native Win32 binary of Emacs on Windows, for those who want to skip
+ the complex explanations and ``just do it'':
+
+ 1. Change to the `nt' directory (the directory of this file):
+
+ cd nt
+
+ 2. Run configure.bat. From the COMMAND.COM/CMD.EXE command prompt:
+
+ configure
+
+ from a Unixy shell prompt:
+
+ cmd /c configure.bat
+ or
+ command.com /c configure.bat
+
+ 3. Run the Make utility suitable for your environment. If you build
+ with the Microsoft's Visual C compiler:
+
+ nmake
+
+ For the development environments based on GNU GCC (MinGW, MSYS,
+ Cygwin - but see notes about Cygwin make below), depending on how
+ Make is called, it could be:
+
+ make
+ or
+ mingw32-make
+ or
+ gnumake
+ or
+ gmake
+
+ (If you are building from CVS, say "make bootstrap" or "nmake
+ bootstrap" instead and avoid using Cygwin make.)
+
+ 4. Generate the Info manuals (only if you are building out of CVS, and
+ if you have makeinfo.exe installed):
+
+ make info
+
+ (change "make" to "nmake" if you use MSVC).
+
+ 5. Install the produced binaries:
+
+ make install
+
+ That's it!
+
+ If these short instructions somehow fail, read the rest of this
+ file.
+
+* Preliminaries
+
+ If you used WinZip to unpack the distribution, we suggest to
+ remove the files and unpack again with a different program!
+ WinZip is known to create some subtle and hard to debug problems,
+ such as converting files to DOS CR-LF format, not creating empty
+ directories, etc. We suggest to use djtarnt.exe from the GNU FTP
+ site.
+
+ If you are building out of CVS, then some files in this directory
+ (.bat files, nmake.defs and makefile.w32-in) may need the line-ends
+ fixing first. The easiest way to do this and avoid future conflicts
+ is to run the following command in this (emacs/nt) directory:
+
+ cvs update -kb
+
+ Alternatively, use programs that convert end-of-line format, such as
+ dos2unix and unix2dos available from GnuWin32 or dtou and utod from
+ the DJGPP project.
+
+ In addition to this file, you should also read INSTALL.CVS in the
+ parent directory, and make sure that you have a version of
+ "touch.exe" in your path, and that it will create files that do not
+ yet exist.
+
+* Supported development environments
+
+ To compile Emacs, you will need either Microsoft Visual C++ 2.0 or
+ later and nmake, or a Windows port of GCC 2.95 or later with MinGW
+ and W32 API support and a port of GNU Make. You can use the Cygwin
+ ports of GCC, but Emacs requires the MinGW headers and libraries to
+ build (latest versions of the Cygwin toolkit, at least since v1.3.3,
+ include the MinGW headers and libraries as an integral part).
+
+ The rest of this file assumes you have a working development
+ environment. If you just installed such an environment, try
+ building a trivial C "Hello world" program, and see if it works. If
+ it doesn't work, resolve that problem first!
+
+ If you use the MinGW port of GCC and GNU Make to build Emacs, there
+ are some compatibility issues wrt Make and the shell that is run by
+ Make, either the standard COMMAND.COM/CMD.EXE supplied with Windows
+ or sh.exe., a port of a Unixy shell. For reference, below is a list
+ of which builds of GNU Make are known to work or not, and whether
+ they work in the presence and/or absence of sh.exe, the Cygwin port
+ of Bash. Note that any version of Make that is compiled with Cygwin
+ will only work with Cygwin tools, due to the use of cygwin style
+ paths. This means Cygwin Make is unsuitable for building parts of
+ Emacs that need to invoke Emacs itself (leim and "make bootstrap",
+ for example). Also see the Trouble-shooting section below if you
+ decide to go ahead and use Cygwin make.
+
+ In addition, using 4NT as your shell is known to fail the build process,
+ at least for 4NT version 3.01. Use CMD.EXE, the default Windows shell,
+ instead. MSYS sh.exe also appears to cause various problems. If you have
+ MSYS installed, try "make SHELL=cmd.exe" to force the use of cmd.exe
+ instead of sh.exe.
+
+ sh exists no sh
+
+ cygwin b20.1 make (3.75): fails[1, 5] fails[2, 5]
+ MSVC compiled gmake 3.77: okay okay
+ MSVC compiled gmake 3.78.1: okay okay
+ MSVC compiled gmake 3.79.1: okay okay
+ mingw32/gcc-2.92.2 make (3.77): okay okay[4]
+ cygwin compiled gmake 3.77: fails[1, 5] fails[2, 5]
+ cygwin compiled make 3.78.1: fails[5] fails[2, 5]
+ cygwin compiled make 3.79.1: fails[3, 5] fails[2?, 5]
+ cygwin compiled make 3.80: fails?[6] fails?[6]
+ cygwin compiled make 3.81: fails fails?[6]
+ mingw32 compiled make 3.79.1: okay okay
+ mingw32 compiled make 3.80: okay unknown[6]
+ mingw32 compiled make 3.81: okay okay[7]
+
+ Notes:
+
+ [1] doesn't cope with makefiles with DOS line endings, so must mount
+ emacs source with text!=binary.
+ [2] fails when needs to invoke shell commands; okay invoking gcc etc.
+ [3] requires LC_MESSAGES support to build; cannot build with early
+ versions of cygwin.
+ [4] may fail on Windows 9X and Windows ME; if so, install Bash.
+ [5] fails when building leim due to the use of cygwin style paths.
+ May work if building emacs without leim.
+ [6] please report if you try this combination.
+ [7] tested only on Windows XP.
+
+ Other compilers may work, but specific reports from people that have
+ tried suggest that the Intel C compiler (for example) may produce an
+ Emacs executable with strange filename completion behaviour. Unless
+ you would like to assist by finding and fixing the cause of any bugs
+ like this, we recommend the use of the supported compilers mentioned
+ in the previous paragraph.
+
+ You will also need a copy of the Posix cp, rm and mv programs. These
+ and other useful Posix utilities can be obtained from one of several
+ projects:
+
+ * http://gnuwin32.sourceforge.net/ ( GnuWin32 )
+ * http://www.mingw.org/ ( MinGW )
+ * http://www.cygwin.com/ ( Cygwin )
+ * http://unxutils.sourceforge.net/ ( UnxUtils )
+
+ If you build Emacs on Windows 9X or ME, not on Windows 2K/XP or
+ Windows NT, we suggest to install the Cygwin port of Bash. That is
+ because the native Windows shell COMMAND.COM is too limited; the
+ Emacs build procedure tries very hard to support even such limited
+ shells, but as none of the Windows developers of Emacs work on
+ Windows 9x, we cannot guarantee that it works without a more
+ powerful shell.
+
+ Additional instructions and help for building Emacs on Windows can be
+ found at the Emacs Wiki:
+
+ http://www.emacswiki.org/cgi-bin/wiki/WThirtyTwoInstallationKit
+
+ and at this URL:
+
+ http://ourcomments.org/Emacs/w32-build-emacs.html
+
+* Configuring
+
+ Configuration of Emacs is now handled by running configure.bat in the
+ `nt' subdirectory. It will detect which compiler you have available,
+ and generate makefiles accordingly. You can override the compiler
+ detection, and control optimization and debug settings, by specifying
+ options on the command line when invoking configure.
+
+ To configure Emacs to build with GCC or MSVC, whichever is available,
+ simply change to the `nt' subdirectory and run `configure.bat' with no
+ options. To see what options are available, run `configure --help'.
+
+ N.B. It is normal to see a few error messages output while configure
+ is running, when gcc support is being tested. These cannot be
+ surpressed because of limitations in the Windows 9x command.com shell.
+
+ You are encouraged to look at the file config.log which shows details
+ for failed tests, after configure.bat finishes. Any unexplained failure
+ should be investigated and perhaps reported as a bug (see the section
+ about reporting bugs in the file README in this directory and in the
+ Emacs manual).
+
+* Optional image library support
+
+ In addition to its "native" image formats (pbm and xbm), Emacs can
+ handle other image types: xpm, tiff, gif, png and jpeg (postscript is
+ currently unsupported on Windows). To build Emacs with support for
+ them, the corresponding headers must be in the include path when the
+ configure script is run. This can be setup using environment
+ variables, or by specifying --cflags -I... options on the command-line
+ to configure.bat. The configure script will report whether it was
+ able to detect the headers. If the results of this testing appear to be
+ incorrect, please look for details in the file config.log: it will show
+ the failed test programs and compiler error messages that should explain
+ what is wrong. (Usually, any such failures happen because some headers
+ are missing due to bad packaging of the image support libraries.)
+
+ To use the external image support, the DLLs implementing the
+ functionality must be found when Emacs first needs them, either on the
+ PATH, or in the same directory as emacs.exe. Failure to find a
+ library is not an error; the associated image format will simply be
+ unavailable. Note that once Emacs has determined that a library can
+ not be found, there's no way to force it to try again, other than
+ restarting. See the variable `image-library-alist' to configure the
+ expected names of the libraries.
+
+ Some image libraries have dependencies on one another, or on zlib.
+ For example, tiff support depends on the jpeg library. If you did not
+ compile the libraries yourself, you must make sure that any dependency
+ is in the PATH or otherwise accesible and that the binaries are
+ compatible (for example, that they were built with the same compiler).
+
+ Binaries for the image libraries (among many others) can be found at
+ the GnuWin32 project. These are built with MinGW, but they can be
+ used with both GCC/MinGW and MSVC builds of Emacs. See the info on
+ http://ourcomments.org/Emacs/EmacsW32.html for more details about
+ installing image support libraries.
+
+* Building
+
+ After running configure, simply run the appropriate `make' program for
+ your compiler to build Emacs. For MSVC, this is nmake; for GCC, it is
+ GNU make. (If you are building out of CVS, say "make bootstrap" or
+ "nmake bootstrap" instead.)
+
+ As the files are compiled, you will see some warning messages
+ declaring that some functions don't return a value, or that some data
+ conversions will be lossy, etc. You can safely ignore these messages.
+ The warnings may be fixed in the main FSF source at some point, but
+ until then we will just live with them.
+
+ If you are building from CVS, the following commands will produce
+ the Info manuals (which are not part of the CVS repository):
+
+ make info
+ or
+ nmake info
+
+ Note that you will need makeinfo.exe (from the GNU Texinfo package)
+ in order for this command to succeed.
+
+* Installing
+
+ To install Emacs after it has compiled, simply run `nmake install'
+ or `make install', depending on which version of the Make utility
+ do you have.
+
+ By default, Emacs will be installed in the location where it was
+ built, but a different location can be specified either using the
+ --prefix option to configure, or by setting INSTALL_DIR when running
+ make, like so:
+
+ make install INSTALL_DIR=D:/emacs
+
+ (for `nmake', type "nmake install INSTALL_DIR=D:/emacs" instead).
+
+ The install process will run addpm to setup the registry entries, and
+ to create a Start menu icon for Emacs.
+
+* Trouble-shooting
+
+ The main problems that are likely to be encountered when building
+ Emacs stem from using an old version of GCC, or old MinGW or W32 API
+ headers. Additionally, cygwin ports of GNU make may require the Emacs
+ source tree to be mounted with text!=binary, because the makefiles
+ generated by configure.bat necessarily use DOS line endings. Also,
+ cygwin ports of make must run in UNIX mode, either by specifying
+ --unix on the command line, or MAKE_MODE=UNIX in the environment.
+
+ When configure runs, it attempts to detect when GCC itself, or the
+ headers it is using, are not suitable for building Emacs. GCC version
+ 2.95 or later is needed, because that is when the Windows port gained
+ sufficient support for anonymous structs and unions to cope with some
+ definitions from winnt.h that are used by addsection.c. The W32 API
+ headers that come with Cygwin b20.1 are incomplete, and do not include
+ some definitions required by addsection.c, for instance. Also, older
+ releases of the W32 API headers from Anders Norlander contain a typo
+ in the definition of IMAGE_FIRST_SECTION in winnt.h, which
+ addsection.c relies on. Versions of w32api-xxx.zip from at least
+ 1999-11-18 onwards are okay.
+
+ When in doubt about correctness of what configure did, look at the file
+ config.log, which shows all the failed test programs and compiler
+ messages associated with the failures. If that doesn't give a clue,
+ please report the problems, together with the relevant fragments from
+ config.log, as bugs.
+
+ If configure succeeds, but make fails, install the Cygwin port of
+ Bash, even if the table above indicates that Emacs should be able to
+ build without sh.exe. (Some versions of Windows shells are too dumb
+ for Makefile's used by Emacs.)
+
+ If you are using certain Cygwin builds of GCC, such as Cygwin version
+ 1.1.8, you may need to specify some extra compiler flags like so:
+
+ configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
+ --ldflags -mwin32
+
+ However, the latest Cygwin versions, such as 1.3.3, don't need those
+ switches; you can simply use "configure --with-gcc".
+
+ We will attempt to auto-detect the need for these flags in a future
+ release.
+
+* Debugging
+
+ You should be able to debug Emacs using the debugger that is
+ appropriate for the compiler you used, namely DevStudio or Windbg if
+ compiled with MSVC, or GDB if compiled with GCC.
+
+ When Emacs aborts due to a fatal internal error, Emacs on Windows
+ pops up an Emacs Abort Dialog asking you whether you want to debug
+ Emacs or terminate it. If Emacs was built with MSVC, click YES
+ twice, and Windbg or the DevStudio debugger will start up
+ automatically. If Emacs was built with GCC, first start GDB and
+ attach it to the Emacs process with the "gdb -p EMACS-PID" command,
+ where EMACS-PID is the Emacs process ID (which you can see in the
+ Windows Task Manager), type the "continue" command inside GDB, and
+ only then click YES on the abort dialog. This will pass control to
+ the debugger, and you will be able to debug the cause of the fatal
+ error.
+
+ Emacs functions implemented in C use a naming convention that reflects
+ their names in lisp. The names of the C routines are the lisp names
+ prefixed with 'F', and with dashes converted to underscores. For
+ example, the function call-process is implemented in C by
+ Fcall_process. Similarly, lisp variables are prefixed with 'V', again
+ with dashes converted to underscores. These conventions enable you to
+ easily set breakpoints or examine familiar lisp variables by name.
+
+ Since Emacs data is often in the form of a lisp object, and the
+ Lisp_Object type is difficult to examine manually in a debugger,
+ Emacs provides a helper routine called debug_print that prints out a
+ readable representation of a Lisp_Object. If you are using GDB,
+ there is a .gdbinit file in the src directory which provides
+ definitions that are useful for examining lisp objects. Therefore,
+ the following tips are mainly of interest when using MSVC.
+
+ The output from debug_print is sent to stderr, and to the debugger
+ via the OutputDebugString routine. The output sent to stderr should
+ be displayed in the console window that was opened when the
+ emacs.exe executable was started. The output sent to the debugger
+ should be displayed in its "Debug" output window.
+
+ When you are in the process of debugging Emacs and you would like to
+ examine the contents of a Lisp_Object variable, popup the QuickWatch
+ window (QuickWatch has an eyeglass symbol on its button in the
+ toolbar). In the text field at the top of the window, enter
+ debug_print(<variable>) and hit return. For example, start and run
+ Emacs in the debugger until it is waiting for user input. Then click
+ on the Break button in the debugger to halt execution. Emacs should
+ halt in ZwUserGetMessage waiting for an input event. Use the Call
+ Stack window to select the procedure w32_msp_pump up the call stack
+ (see below for why you have to do this). Open the QuickWatch window
+ and enter debug_print(Vexec_path). Evaluating this expression will
+ then print out the contents of the lisp variable exec-path.
+
+ If QuickWatch reports that the symbol is unknown, then check the call
+ stack in the Call Stack window. If the selected frame in the call
+ stack is not an Emacs procedure, then the debugger won't recognize
+ Emacs symbols. Instead, select a frame that is inside an Emacs
+ procedure and try using debug_print again.
+
+ If QuickWatch invokes debug_print but nothing happens, then check the
+ thread that is selected in the debugger. If the selected thread is
+ not the last thread to run (the "current" thread), then it cannot be
+ used to execute debug_print. Use the Debug menu to select the current
+ thread and try using debug_print again. Note that the debugger halts
+ execution (e.g., due to a breakpoint) in the context of the current
+ thread, so this should only be a problem if you've explicitly switched
+ threads.
+
+COPYING PERMISSIONS
+
+ Permission is granted to anyone to make or distribute verbatim copies
+ of this document as received, in any medium, provided that the
+ copyright notice and permission notice are preserved,
+ and that the distributor grants the recipient permission
+ for further redistribution as permitted by this notice.
+
+ Permission is granted to distribute modified versions
+ of this document, or of portions of it,
+ under the above conditions, provided also that they
+ carry prominent notices stating who last changed them,
+ and that any new or changed statements about the activities
+ of the Free Software Foundation are approved by the Foundation.