| 1 | Building and Installing Emacs on Windows |
| 2 | (from 95 to 7 and beyond) |
| 3 | |
| 4 | Copyright (C) 2001-2014 Free Software Foundation, Inc. |
| 5 | See the end of the file for license conditions. |
| 6 | |
| 7 | *** This method of building Emacs is no longer supported. *** |
| 8 | It may fail to produce a correctly working Emacs. |
| 9 | Do not report bugs associated with this build method. |
| 10 | Instead, follow the new instructions in INSTALL. |
| 11 | |
| 12 | * For the impatient |
| 13 | |
| 14 | Here are the concise instructions for configuring and building the |
| 15 | native Windows binary of Emacs, for those who want to skip the |
| 16 | complex explanations and ``just do it'': |
| 17 | |
| 18 | Do not use this recipe with Cygwin. For building on Cygwin, |
| 19 | use the normal installation instructions, ../INSTALL. |
| 20 | |
| 21 | Do not use these instructions with MSYS environment. For building |
| 22 | the native Windows binary with MinGW and MSYS, follow the |
| 23 | instructions in the file INSTALL in this directory. |
| 24 | |
| 25 | For building without MSYS, if you have a Cygwin or MSYS port of Bash |
| 26 | on your Path, you will be better off removing it from PATH. (For |
| 27 | details, search for "MSYS sh.exe" below.) |
| 28 | |
| 29 | 1. Change to the `nt' directory (the directory of this file): |
| 30 | |
| 31 | cd nt |
| 32 | |
| 33 | 2. Run configure.bat. |
| 34 | |
| 35 | 2a.If you use MSVC, set up the build environment by running the |
| 36 | SetEnv.cmd batch file from the appropriate SDK directory. (Skip |
| 37 | this step if you are using MinGW.) For example: |
| 38 | |
| 39 | "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /Debug |
| 40 | |
| 41 | if you are going to compile a debug version, or |
| 42 | |
| 43 | "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /Release |
| 44 | |
| 45 | if you are going to compile an optimized version. |
| 46 | |
| 47 | 2b.From the COMMAND.COM/CMD.EXE command prompt type: |
| 48 | |
| 49 | configure |
| 50 | |
| 51 | From a Unixy shell prompt: |
| 52 | |
| 53 | cmd /c configure.bat |
| 54 | or |
| 55 | command.com /c configure.bat |
| 56 | |
| 57 | 3. Run the Make utility suitable for your environment. If you build |
| 58 | with the Microsoft's Visual C compiler: |
| 59 | |
| 60 | nmake |
| 61 | |
| 62 | For the development environments based on GNU GCC (MinGW, MSYS, |
| 63 | Cygwin - but see notes about Cygwin make below), depending on how |
| 64 | Make is called, it could be: |
| 65 | |
| 66 | make |
| 67 | or |
| 68 | mingw32-make |
| 69 | or |
| 70 | gnumake |
| 71 | or |
| 72 | gmake |
| 73 | |
| 74 | (If you are building from Bazaar, say "make bootstrap" or "nmake |
| 75 | bootstrap" instead, and avoid using Cygwin make.) |
| 76 | |
| 77 | With GNU Make, you can use the -j command-line option to have |
| 78 | Make execute several commands at once, like this: |
| 79 | |
| 80 | gmake -j 2 |
| 81 | |
| 82 | (With versions of GNU Make before 3.82, you need also set the |
| 83 | XMFLAGS variable, like this: |
| 84 | |
| 85 | gmake -j 2 XMFLAGS="-j 2" |
| 86 | |
| 87 | The XMFLAGS variable overrides the default behavior of version |
| 88 | 3.82 and older of GNU Make on Windows, whereby recursive Make |
| 89 | invocations reset the maximum number of simultaneous commands to |
| 90 | 1. The above command allows up to 4 simultaneous commands at |
| 91 | once in the top-level Make, and up to 3 in each one of the |
| 92 | recursive Make's.) |
| 93 | |
| 94 | 4. Generate the Info manuals (only if you are building out of Bazaar, |
| 95 | and if you have makeinfo.exe installed): |
| 96 | |
| 97 | make info |
| 98 | |
| 99 | (change "make" to "nmake" if you use MSVC). |
| 100 | |
| 101 | 5. Install the produced binaries: |
| 102 | |
| 103 | make install |
| 104 | |
| 105 | That's it! |
| 106 | |
| 107 | If these short instructions somehow fail, read the rest of this |
| 108 | file. |
| 109 | |
| 110 | * Preliminaries |
| 111 | |
| 112 | If you want to build a Cygwin port of Emacs, use the instructions in |
| 113 | the INSTALL file in the main Emacs directory (the parent of this |
| 114 | directory). These instructions are for building a native Windows |
| 115 | binary of Emacs. |
| 116 | |
| 117 | If you used WinZip to unpack the distribution, we suggest to |
| 118 | remove the files and unpack again with a different program! |
| 119 | WinZip is known to create some subtle and hard to debug problems, |
| 120 | such as converting files to DOS CR-LF format, not creating empty |
| 121 | directories, etc. We suggest to use djtarnt.exe from the GNU FTP |
| 122 | site. For modern formats, such as .tar.xz, we suggest bsdtar.exe |
| 123 | from the libarchive package; its precompiled Windows binaries are |
| 124 | available from this site: |
| 125 | |
| 126 | http://sourceforge.net/projects/ezwinports/files/ |
| 127 | |
| 128 | In addition to this file, if you build a development snapshot, you |
| 129 | should also read INSTALL.BZR in the parent directory. |
| 130 | |
| 131 | * Supported development environments |
| 132 | |
| 133 | To compile Emacs, you will need either Microsoft Visual C++ 2.0, or |
| 134 | later and nmake, or a Windows port of GCC 2.95 or later with MinGW |
| 135 | and Windows API support and a port of GNU Make. You can use the Cygwin |
| 136 | ports of GCC, but Emacs requires the MinGW headers and libraries to |
| 137 | build (latest versions of the Cygwin toolkit, at least since v1.3.3, |
| 138 | include the MinGW headers and libraries as an integral part). |
| 139 | |
| 140 | The rest of this file assumes you have a working development |
| 141 | environment. If you just installed such an environment, try |
| 142 | building a trivial C "Hello world" program, and see if it works. If |
| 143 | it doesn't work, resolve that problem first! If you use Microsoft |
| 144 | Visual Studio .NET 2003, don't forget to run the VCVARS32.BAT batch |
| 145 | file from the `Bin' subdirectory of the directory where you have |
| 146 | installed VS.NET. With other versions of MSVC, run the SetEnv.cmd |
| 147 | batch file from the `Bin' subdirectory of the directory where you |
| 148 | have the SDK installed. |
| 149 | |
| 150 | If you use the MinGW port of GCC and GNU Make to build Emacs, there |
| 151 | are some compatibility issues wrt Make and the shell that is run by |
| 152 | Make, either the standard COMMAND.COM/CMD.EXE supplied with Windows |
| 153 | or sh.exe, a port of a Unixy shell. For reference, below is a list |
| 154 | of which builds of GNU Make are known to work or not, and whether |
| 155 | they work in the presence and/or absence of sh.exe, the Cygwin port |
| 156 | of Bash. Note that any version of Make that is compiled with Cygwin |
| 157 | will only work with Cygwin tools, due to the use of Cygwin style |
| 158 | paths. This means Cygwin Make is unsuitable for building parts of |
| 159 | Emacs that need to invoke Emacs itself (leim and "make bootstrap", |
| 160 | for example). Also see the Trouble-shooting section below if you |
| 161 | decide to go ahead and use Cygwin make. |
| 162 | |
| 163 | In addition, using 4NT or TCC as your shell is known to fail the |
| 164 | build process, at least since 4NT version 3.01. Use CMD.EXE, the |
| 165 | default Windows shell, instead. MSYS sh.exe also appears to cause |
| 166 | various problems, e.g., it is known to cause failures in commands |
| 167 | like "cmd /c FOO" in the Makefiles, because it thinks "/c" is a |
| 168 | Unix-style file name that needs conversion to the Windows format. |
| 169 | If you have MSYS installed, try "make SHELL=cmd.exe" to force the |
| 170 | use of cmd.exe instead of the MSYS sh.exe. |
| 171 | |
| 172 | sh exists no sh |
| 173 | |
| 174 | cygwin b20.1 make (3.75): fails[1, 5] fails[2, 5] |
| 175 | MSVC compiled gmake 3.77: okay okay |
| 176 | MSVC compiled gmake 3.78.1: okay okay |
| 177 | MSVC compiled gmake 3.79.1: okay okay |
| 178 | mingw32/gcc-2.92.2 make (3.77): okay okay[4] |
| 179 | cygwin compiled gmake 3.77: fails[1, 5] fails[2, 5] |
| 180 | cygwin compiled make 3.78.1: fails[5] fails[2, 5] |
| 181 | cygwin compiled make 3.79.1: fails[3, 5] fails[2?, 5] |
| 182 | cygwin compiled make 3.80: okay[6] fails?[7] |
| 183 | cygwin compiled make 3.81: fails fails?[7] |
| 184 | mingw32 compiled make 3.79.1: okay okay |
| 185 | mingw32 compiled make 3.80: okay okay[7] |
| 186 | mingw32 compiled make 3.81: okay okay[8] |
| 187 | |
| 188 | Notes: |
| 189 | |
| 190 | [1] doesn't cope with makefiles with DOS line endings, so must mount |
| 191 | emacs source with text!=binary. |
| 192 | [2] fails when needs to invoke shell commands; okay invoking gcc etc. |
| 193 | [3] requires LC_MESSAGES support to build; cannot build with early |
| 194 | versions of Cygwin. |
| 195 | [4] may fail on Windows 9X and Windows ME; if so, install Bash. |
| 196 | [5] fails when building leim due to the use of cygwin style paths. |
| 197 | May work if building emacs without leim. |
| 198 | [6] need to uncomment 3 lines in nt/gmake.defs that invoke `cygpath' |
| 199 | (look for "cygpath" near line 85 of gmake.defs). |
| 200 | [7] not recommended; please report if you try this combination. |
| 201 | [8] tested only on Windows XP. |
| 202 | |
| 203 | Other compilers may work, but specific reports from people that have |
| 204 | tried suggest that the Intel C compiler (for example) may produce an |
| 205 | Emacs executable with strange filename completion behavior. Unless |
| 206 | you would like to assist by finding and fixing the cause of any bugs |
| 207 | like this, we recommend the use of the supported compilers mentioned |
| 208 | in the previous paragraph. |
| 209 | |
| 210 | You will also need a copy of the POSIX cp, rm and mv programs. These |
| 211 | and other useful POSIX utilities can be obtained from one of several |
| 212 | projects: |
| 213 | |
| 214 | * http://gnuwin32.sourceforge.net/ ( GnuWin32 ) |
| 215 | * http://www.mingw.org/ ( MinGW ) |
| 216 | * http://www.cygwin.com/ ( Cygwin ) |
| 217 | * http://unxutils.sourceforge.net/ ( UnxUtils ) |
| 218 | |
| 219 | If you build Emacs on 16-bit versions of Windows (9X or ME), we |
| 220 | suggest to install the Cygwin port of Bash. That is because the |
| 221 | native Windows shell COMMAND.COM is too limited; the Emacs build |
| 222 | procedure tries very hard to support even such limited shells, but |
| 223 | as none of the Windows developers of Emacs work on Windows 9X, we |
| 224 | cannot guarantee that it works without a more powerful shell. |
| 225 | |
| 226 | Additional instructions and help for building Emacs on Windows can be |
| 227 | found at the Emacs Wiki: |
| 228 | |
| 229 | http://www.emacswiki.org/cgi-bin/wiki/WThirtyTwoInstallationKit |
| 230 | |
| 231 | and on these URLs: |
| 232 | |
| 233 | http://ourcomments.org/Emacs/w32-build-emacs.html |
| 234 | http://derekslager.com/blog/posts/2007/01/emacs-hack-3-compile-emacs-from-cvs-on-windows.ashx |
| 235 | |
| 236 | Both of those pages were written before Emacs switched from CVS to |
| 237 | Bazaar, but the parts about building Emacs still apply in Bazaar. |
| 238 | The second URL has instructions for building with MSVC, as well as |
| 239 | with MinGW, while the first URL covers only MinGW, but has more |
| 240 | details about it. |
| 241 | |
| 242 | * Configuring |
| 243 | |
| 244 | Configuration of Emacs is now handled by running configure.bat in the |
| 245 | `nt' subdirectory. It will detect which compiler you have available, |
| 246 | and generate makefiles accordingly. You can override the compiler |
| 247 | detection, and control optimization and debug settings, by specifying |
| 248 | options on the command line when invoking configure. |
| 249 | |
| 250 | To configure Emacs to build with GCC or MSVC, whichever is available, |
| 251 | simply change to the `nt' subdirectory and run `configure.bat' with no |
| 252 | options. To see what options are available, run `configure --help'. |
| 253 | Do NOT use the --no-debug option to configure.bat unless you are |
| 254 | absolutely sure the produced binaries will never need to be run under |
| 255 | a debugger. |
| 256 | |
| 257 | Because of limitations of the stock Windows command shells, special |
| 258 | care is needed to pass some characters in the arguments of the |
| 259 | --cflags and --ldflags options. Backslashes should not be used in |
| 260 | file names passed to the compiler and linker via these options. Use |
| 261 | forward slashes instead. If the arguments to these two options |
| 262 | include the `=' character, like when passing a -DFOO=bar preprocessor |
| 263 | option, the argument with the `=' character should be enclosed in |
| 264 | quotes, like this: |
| 265 | |
| 266 | configure --cflags "-DFOO=bar" |
| 267 | |
| 268 | Support for options that include the `=' character require "command |
| 269 | extensions" to be enabled. (They are enabled by default, but your |
| 270 | system administrator could have changed that. See "cmd /?" for |
| 271 | details.) If command extensions are disabled, a warning message might |
| 272 | be displayed informing you that "using parameters that include the = |
| 273 | character by enclosing them in quotes will not be supported." |
| 274 | |
| 275 | You may also use the --cflags and --ldflags options to pass |
| 276 | additional parameters to the compiler and linker, respectively; they |
| 277 | are frequently used to pass -I and -L flags to specify supplementary |
| 278 | include and library directories. If a directory name includes |
| 279 | spaces, you will need to enclose it in quotes, as follows |
| 280 | -I"C:/Program Files/GnuTLS-2.10.1/include". Note that only the |
| 281 | directory name is enclosed in quotes, not the entire argument. Also |
| 282 | note that this functionality is only supported if command extensions |
| 283 | are available. If command extensions are disabled and you attempt to |
| 284 | use this functionality you may see the following warning message |
| 285 | "Error in --cflags argument: ... Backslashes and quotes cannot be |
| 286 | used with --cflags. Please use forward slashes for filenames and |
| 287 | paths (e.g. when passing directories to -I)." |
| 288 | |
| 289 | N.B. It is normal to see a few error messages output while configure |
| 290 | is running, when gcc support is being tested. These cannot be |
| 291 | suppressed because of limitations in the Windows 9X command.com shell. |
| 292 | |
| 293 | You are encouraged to look at the file config.log which shows details |
| 294 | for failed tests, after configure.bat finishes. Any unexplained failure |
| 295 | should be investigated and perhaps reported as a bug (see the section |
| 296 | about reporting bugs in the file README in this directory and in the |
| 297 | Emacs manual). |
| 298 | |
| 299 | * Optional image library support |
| 300 | |
| 301 | In addition to its "native" image formats (pbm and xbm), Emacs can |
| 302 | handle other image types: xpm, tiff, gif, png, jpeg and experimental |
| 303 | support for svg. |
| 304 | |
| 305 | To build Emacs with support for them, the corresponding headers must |
| 306 | be in the include path when the configure script is run. This can |
| 307 | be setup using environment variables, or by specifying --cflags |
| 308 | -I... options on the command-line to configure.bat. The configure |
| 309 | script will report whether it was able to detect the headers. If |
| 310 | the results of this testing appear to be incorrect, please look for |
| 311 | details in the file config.log: it will show the failed test |
| 312 | programs and compiler error messages that should explain what is |
| 313 | wrong. (Usually, any such failures happen because some headers are |
| 314 | missing due to bad packaging of the image support libraries.) |
| 315 | |
| 316 | Note that any file path passed to the compiler or linker must use |
| 317 | forward slashes; using backslashes will cause compiler warnings or |
| 318 | errors about unrecognized escape sequences. |
| 319 | |
| 320 | To use the external image support, the DLLs implementing the |
| 321 | functionality must be found when Emacs first needs them, either on the |
| 322 | PATH, or in the same directory as emacs.exe. Failure to find a |
| 323 | library is not an error; the associated image format will simply be |
| 324 | unavailable. Note that once Emacs has determined that a library can |
| 325 | not be found, there's no way to force it to try again, other than |
| 326 | restarting. See the variable `dynamic-library-alist' to configure the |
| 327 | expected names of the libraries. |
| 328 | |
| 329 | Some image libraries have dependencies on one another, or on zlib. |
| 330 | For example, tiff support depends on the jpeg library. If you did not |
| 331 | compile the libraries yourself, you must make sure that any dependency |
| 332 | is in the PATH or otherwise accessible and that the binaries are |
| 333 | compatible (for example, that they were built with the same compiler). |
| 334 | |
| 335 | Binaries for the image libraries (among many others) can be found at |
| 336 | the GnuWin32 project. PNG, JPEG and TIFF libraries are also |
| 337 | included with GTK, which is installed along with other Free Software |
| 338 | that requires it. These are built with MinGW, but they can be used |
| 339 | with both GCC/MinGW and MSVC builds of Emacs. See the info on |
| 340 | http://ourcomments.org/Emacs/w32-build-emacs.html, under "How to Get |
| 341 | Images Support", for more details about installing image support |
| 342 | libraries. Note specifically that, due to some packaging snafus in |
| 343 | the GnuWin32-supplied image libraries, you will need to download |
| 344 | _source_ packages for some of the libraries in order to get the |
| 345 | header files necessary for building Emacs with image support. |
| 346 | |
| 347 | If GTK 2.0 is installed, addpm will arrange for its image libraries |
| 348 | to be on the DLL search path for Emacs. |
| 349 | |
| 350 | For PNG images, we recommend to use versions 1.4.x and later of |
| 351 | libpng, because previous versions had security issues. You can find |
| 352 | precompiled libraries and headers on the GTK download page for |
| 353 | Windows (http://www.gtk.org/download/win32.php). |
| 354 | |
| 355 | Versions 1.4.0 and later of libpng are binary incompatible with |
| 356 | earlier versions, so Emacs will only look for libpng libraries which |
| 357 | are compatible with the version it was compiled against. That |
| 358 | version is given by the value of the Lisp variable `libpng-version'; |
| 359 | e.g., 10403 means version 1.4.3. The variable `dynamic-library-alist' |
| 360 | is automatically set to name only those DLL names that are known to |
| 361 | be compatible with the version given by `libpng-version'. If PNG |
| 362 | support does not work for you even though you have the support DLL |
| 363 | installed, check the name of the installed DLL against |
| 364 | `dynamic-library-alist' and the value of `libpng-version', and |
| 365 | download compatible DLLs if needed. |
| 366 | |
| 367 | * Optional GnuTLS support |
| 368 | |
| 369 | If configure.bat finds the gnutls/gnutls.h file in the include path, |
| 370 | Emacs is built with GnuTLS support by default; to avoid that you can |
| 371 | pass the argument --without-gnutls. |
| 372 | |
| 373 | In order to support GnuTLS at runtime, a GnuTLS-enabled Emacs must |
| 374 | be able to find the relevant DLLs during startup; failure to do so |
| 375 | is not an error, but GnuTLS won't be available to the running |
| 376 | session. |
| 377 | |
| 378 | You can get pre-built binaries (including any required DLL and the |
| 379 | header files) at http://sourceforge.net/projects/ezwinports/files/. |
| 380 | |
| 381 | * Optional libxml2 support |
| 382 | |
| 383 | If configure.bat finds the libxml/HTMLparser.h file in the include path, |
| 384 | Emacs is built with libxml2 support by default; to avoid that you can |
| 385 | pass the argument --without-libxml2. |
| 386 | |
| 387 | In order to support libxml2 at runtime, a libxml2-enabled Emacs must |
| 388 | be able to find the relevant DLLs during startup; failure to do so |
| 389 | is not an error, but libxml2 features won't be available to the |
| 390 | running session. |
| 391 | |
| 392 | One place where you can get pre-built Windows binaries of libxml2 |
| 393 | (including any required DLL and the header files) is here: |
| 394 | |
| 395 | http://sourceforge.net/projects/ezwinports/files/ |
| 396 | |
| 397 | To compile Emacs with libxml2 from that site, you will need to pass |
| 398 | the "--cflags -I/path/to/include/libxml2" option to configure.bat, |
| 399 | because libxml2 header files are installed in the include/libxml2 |
| 400 | subdirectory of the directory where you unzip the binary |
| 401 | distribution. Other binary distributions might use other |
| 402 | directories, although include/libxml2 is the canonical place where |
| 403 | libxml2 headers are installed on Posix platforms. |
| 404 | |
| 405 | You will also need to install the libiconv "development" tarball, |
| 406 | because the libiconv headers need to be available to the compiler |
| 407 | when you compile with libxml2 support. A MinGW port of libiconv can |
| 408 | be found on the MinGW site: |
| 409 | |
| 410 | http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/ |
| 411 | |
| 412 | You need the libiconv-X.Y.Z-N-mingw32-dev.tar.lzma tarball from that |
| 413 | site. |
| 414 | |
| 415 | * Experimental SVG support |
| 416 | |
| 417 | SVG support is currently experimental, and not built by default. |
| 418 | Specify --with-svg and ensure you have all the dependencies in your |
| 419 | include path. Unless you have built a minimalist librsvg yourself |
| 420 | (untested), librsvg depends on a significant chunk of GTK+ to build, |
| 421 | plus a few Gnome libraries, libxml2, libbz2 and zlib at runtime. The |
| 422 | easiest way to obtain the dependencies required for building is to |
| 423 | download a pre-bundled GTK+ development environment for Windows. |
| 424 | GTK puts its header files all over the place, so you will need to |
| 425 | run pkgconfig to list the include path you will need (either passed |
| 426 | to configure.bat as --cflags options, or set in the environment). |
| 427 | |
| 428 | To use librsvg at runtime, ensure that librsvg and its dependencies |
| 429 | are on your PATH. If you didn't build librsvg yourself, you will |
| 430 | need to check with where you downloaded it from for the |
| 431 | dependencies, as there are different build options. If it is a |
| 432 | short list, then it most likely only lists the immediate |
| 433 | dependencies of librsvg, but the dependencies themselves have |
| 434 | dependencies - so don't download individual libraries from GTK+, |
| 435 | download and install the whole thing. If you think you've got all |
| 436 | the dependencies and SVG support is still not working, check your |
| 437 | PATH for other libraries that shadow the ones you downloaded. |
| 438 | Libraries of the same name from different sources may not be |
| 439 | compatible, this problem was encountered with libbzip2 from GnuWin32 |
| 440 | with libcroco from gnome.org. |
| 441 | |
| 442 | If you can see etc/images/splash.svg, then you have managed to get |
| 443 | SVG support working. Congratulations for making it through DLL hell |
| 444 | to this point. You'll probably find that some SVG images crash |
| 445 | Emacs. Problems have been observed in some images that contain |
| 446 | text, they seem to be a problem in the Windows port of Pango, or |
| 447 | maybe a problem with the way Cairo or librsvg is using it that |
| 448 | doesn't show up on other platforms. |
| 449 | |
| 450 | * Optional extra runtime checks |
| 451 | |
| 452 | The configure.bat option --enable-checking builds Emacs with some |
| 453 | optional extra runtime checks and assertions enabled. This may be |
| 454 | useful for debugging. |
| 455 | |
| 456 | * Optional extra libraries |
| 457 | |
| 458 | You can pass --lib LIBNAME option to configure.bat to cause Emacs to |
| 459 | link with the specified library. You can use this option more than once. |
| 460 | |
| 461 | * Building |
| 462 | |
| 463 | After running configure, simply run the appropriate `make' program for |
| 464 | your compiler to build Emacs. For MSVC, this is nmake; for GCC, it is |
| 465 | GNU make. (If you are building out of Bazaar, say "make bootstrap" or |
| 466 | "nmake bootstrap" instead.) |
| 467 | |
| 468 | As the files are compiled, you will see some warning messages |
| 469 | declaring that some functions don't return a value, or that some data |
| 470 | conversions will be lossy, etc. You can safely ignore these messages. |
| 471 | The warnings may be fixed in the main FSF source at some point, but |
| 472 | until then we will just live with them. |
| 473 | |
| 474 | With GNU Make, you can use the -j command-line option to have Make |
| 475 | execute several commands at once, like this: |
| 476 | |
| 477 | gmake -j 4 XMFLAGS="-j 3" |
| 478 | |
| 479 | The XMFLAGS variable overrides the default behavior of GNU Make on |
| 480 | Windows, whereby recursive Make invocations reset the maximum number |
| 481 | of simultaneous commands to 1. The above command allows up to 4 |
| 482 | simultaneous commands at once in the top-level Make, and up to 3 in |
| 483 | each one of the recursive Make's; you can use other numbers of jobs, |
| 484 | if you wish. |
| 485 | |
| 486 | If you are building from Bazaar, the following commands will produce |
| 487 | the Info manuals (which are not part of the Bazaar sources): |
| 488 | |
| 489 | make info |
| 490 | or |
| 491 | nmake info |
| 492 | |
| 493 | Note that you will need makeinfo.exe (from the GNU Texinfo package) |
| 494 | in order for this command to succeed. |
| 495 | |
| 496 | * Installing |
| 497 | |
| 498 | To install Emacs after it has compiled, simply run `nmake install' |
| 499 | or `make install', depending on which version of the Make utility |
| 500 | do you have. |
| 501 | |
| 502 | By default, Emacs will be installed in the location where it was |
| 503 | built, but a different location can be specified either using the |
| 504 | --prefix option to configure, or by setting INSTALL_DIR when running |
| 505 | make, like so: |
| 506 | |
| 507 | make install INSTALL_DIR=D:/emacs |
| 508 | |
| 509 | (for `nmake', type "nmake install INSTALL_DIR=D:/emacs" instead). |
| 510 | |
| 511 | The install process will run addpm to setup the registry entries, and |
| 512 | to create a Start menu icon for Emacs. |
| 513 | |
| 514 | * Make targets |
| 515 | |
| 516 | The following make targets may be used by users building the source |
| 517 | distribution, or users who have checked out of Bazaar after |
| 518 | an initial bootstrapping. |
| 519 | |
| 520 | make |
| 521 | Builds Emacs from the available sources and pre-compiled lisp files. |
| 522 | |
| 523 | make install |
| 524 | Installs programs to the bin directory, and runs addpm to create |
| 525 | Start Menu icons. |
| 526 | |
| 527 | make clean |
| 528 | Removes object and executable files produced by the build process in |
| 529 | the current configuration. After make clean, you can rebuild with |
| 530 | the same configuration using make. |
| 531 | |
| 532 | make distclean |
| 533 | In addition to the files removed by make clean, this also removes |
| 534 | Makefiles and other generated files to get back to the state of a |
| 535 | freshly unpacked source distribution. Note that this will not remove |
| 536 | installed files, or the results of builds performed with different |
| 537 | compiler or optimization options than the current configuration. |
| 538 | After make distclean, it is necessary to run configure.bat followed |
| 539 | by make to rebuild. |
| 540 | |
| 541 | make cleanall |
| 542 | Removes object and executable files that may have been created by |
| 543 | previous builds with different configure options, in addition to |
| 544 | the files produced by the current configuration. |
| 545 | |
| 546 | make realclean |
| 547 | Removes the installed files in the bin subdirectory in addition to |
| 548 | the files removed by make cleanall. |
| 549 | |
| 550 | make dist |
| 551 | Builds Emacs from the available sources and pre-compiled lisp files. |
| 552 | Packages Emacs binaries as full distribution and barebin distribution. |
| 553 | |
| 554 | The following targets are intended only for use with the Bazaar sources. |
| 555 | |
| 556 | make bootstrap |
| 557 | Creates a temporary emacs binary with lisp source files and |
| 558 | uses it to compile the lisp files. Once the lisp files are built, |
| 559 | emacs is redumped with the compiled lisp. |
| 560 | |
| 561 | make recompile |
| 562 | Recompiles any changed lisp files after an update. This saves |
| 563 | doing a full bootstrap after every update. If this or a subsequent |
| 564 | make fail, you probably need to perform a full bootstrap, though |
| 565 | running this target multiple times may eventually sort out the |
| 566 | interdependencies. |
| 567 | |
| 568 | make maintainer-clean |
| 569 | Removes everything that can be recreated, including compiled lisp |
| 570 | files, to get back to the state of a fresh Bazaar tree. After make |
| 571 | maintainer-clean, it is necessary to run configure.bat and make |
| 572 | bootstrap to rebuild. Occasionally it may be necessary to run this |
| 573 | target after an update. |
| 574 | |
| 575 | * Creating binary distributions |
| 576 | |
| 577 | Binary distributions (full and barebin distributions) can be |
| 578 | automatically built and packaged from source tarballs or a bzr |
| 579 | checkout. |
| 580 | |
| 581 | When building Emacs binary distributions, the --distfiles argument |
| 582 | to configure.bat specifies files to be included in the bin directory |
| 583 | of the binary distributions. This is intended for libraries that are |
| 584 | not built as part of Emacs, e.g. image libraries. |
| 585 | |
| 586 | For example, specifying |
| 587 | |
| 588 | --distfiles D:\distfiles\libXpm.dll |
| 589 | |
| 590 | results in libXpm.dll being copied from D:\distfiles to the |
| 591 | bin directory before packaging starts. |
| 592 | |
| 593 | Multiple files can be specified using multiple --distfiles arguments: |
| 594 | |
| 595 | --distfiles D:\distfiles\libXpm.dll --distfiles C:\jpeglib\jpeg.dll |
| 596 | |
| 597 | For packaging the binary distributions, the 'dist' make target uses |
| 598 | 7-Zip (http://www.7-zip.org), which must be installed and available |
| 599 | on the Windows Path. |
| 600 | |
| 601 | |
| 602 | * Trouble-shooting |
| 603 | |
| 604 | The main problems that are likely to be encountered when building |
| 605 | Emacs stem from using an old version of GCC, or old MinGW or Windows API |
| 606 | headers. Additionally, Cygwin ports of GNU make may require the Emacs |
| 607 | source tree to be mounted with text!=binary, because the makefiles |
| 608 | generated by configure.bat necessarily use DOS line endings. Also, |
| 609 | Cygwin ports of make must run in UNIX mode, either by specifying |
| 610 | --unix on the command line, or MAKE_MODE=UNIX in the environment. |
| 611 | |
| 612 | When configure runs, it attempts to detect when GCC itself, or the |
| 613 | headers it is using, are not suitable for building Emacs. GCC version |
| 614 | 2.95 or later is needed, because that is when the Windows port gained |
| 615 | sufficient support for anonymous structs and unions to cope with some |
| 616 | definitions from winnt.h that are used by addsection.c. |
| 617 | Older versions of the Windows API headers that come with Cygwin and MinGW |
| 618 | may be missing some definitions required by Emacs, or broken in other |
| 619 | ways. In particular, uniscribe APIs were added to MinGW CVS only on |
| 620 | 2006-03-26, so releases from before then cannot be used. |
| 621 | |
| 622 | When in doubt about correctness of what configure did, look at the file |
| 623 | config.log, which shows all the failed test programs and compiler |
| 624 | messages associated with the failures. If that doesn't give a clue, |
| 625 | please report the problems, together with the relevant fragments from |
| 626 | config.log, as bugs. |
| 627 | |
| 628 | If configure succeeds, but make fails, install the Cygwin port of |
| 629 | Bash, even if the table above indicates that Emacs should be able to |
| 630 | build without sh.exe. (Some versions of Windows shells are too dumb |
| 631 | for Makefile's used by Emacs.) |
| 632 | |
| 633 | If you are using certain Cygwin builds of GCC, such as Cygwin version |
| 634 | 1.1.8, you may need to specify some extra compiler flags like so: |
| 635 | |
| 636 | configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ |
| 637 | --ldflags -mwin32 |
| 638 | |
| 639 | However, the latest Cygwin versions, such as 1.3.3, don't need those |
| 640 | switches; you can simply use "configure --with-gcc". |
| 641 | |
| 642 | We will attempt to auto-detect the need for these flags in a future |
| 643 | release. |
| 644 | |
| 645 | * Debugging |
| 646 | |
| 647 | You should be able to debug Emacs using the debugger that is |
| 648 | appropriate for the compiler you used, namely DevStudio or Windbg if |
| 649 | compiled with MSVC, or GDB if compiled with GCC. (GDB for Windows |
| 650 | is available from the MinGW site, http://www.mingw.org/download.shtml.) |
| 651 | |
| 652 | When Emacs aborts due to a fatal internal error, Emacs on Windows |
| 653 | pops up an Emacs Abort Dialog asking you whether you want to debug |
| 654 | Emacs or terminate it. If Emacs was built with MSVC, click YES |
| 655 | twice, and Windbg or the DevStudio debugger will start up |
| 656 | automatically. If Emacs was built with GCC, first start GDB and |
| 657 | attach it to the Emacs process with the "gdb -p EMACS-PID" command, |
| 658 | where EMACS-PID is the Emacs process ID (which you can see in the |
| 659 | Windows Task Manager), type the "continue" command inside GDB, and |
| 660 | only then click YES on the abort dialog. This will pass control to |
| 661 | the debugger, and you will be able to debug the cause of the fatal |
| 662 | error. |
| 663 | |
| 664 | The single most important thing to find out when Emacs aborts or |
| 665 | crashes is where did that happen in the Emacs code. This is called |
| 666 | "backtrace". |
| 667 | |
| 668 | Emacs on Windows uses more than one thread. When Emacs aborts due |
| 669 | to a fatal error, the current thread may not be the application |
| 670 | thread running Emacs code. Therefore, to produce a meaningful |
| 671 | backtrace from a debugger, you need to instruct it to show the |
| 672 | backtrace for every thread. With GDB, you do it like this: |
| 673 | |
| 674 | (gdb) thread apply all backtrace |
| 675 | |
| 676 | To run Emacs under a debugger to begin with, simply start it from |
| 677 | the debugger. With GDB, chdir to the `src' directory (if you have |
| 678 | the source tree) or to a directory with the `.gdbinit' file (if you |
| 679 | don't have the source tree), and type these commands: |
| 680 | |
| 681 | C:\whatever\src> gdb x:\path\to\emacs.exe |
| 682 | (gdb) run <ARGUMENTS TO EMACS> |
| 683 | |
| 684 | Thereafter, use Emacs as usual; you can minimize the debugger |
| 685 | window, if you like. The debugger will take control if and when |
| 686 | Emacs crashes. |
| 687 | |
| 688 | Emacs functions implemented in C use a naming convention that reflects |
| 689 | their names in lisp. The names of the C routines are the lisp names |
| 690 | prefixed with 'F', and with dashes converted to underscores. For |
| 691 | example, the function call-process is implemented in C by |
| 692 | Fcall_process. Similarly, lisp variables are prefixed with 'V', again |
| 693 | with dashes converted to underscores. These conventions enable you to |
| 694 | easily set breakpoints or examine familiar lisp variables by name. |
| 695 | |
| 696 | Since Emacs data is often in the form of a lisp object, and the |
| 697 | Lisp_Object type is difficult to examine manually in a debugger, |
| 698 | Emacs provides a helper routine called debug_print that prints out a |
| 699 | readable representation of a Lisp_Object. If you are using GDB, |
| 700 | there is a .gdbinit file in the src directory which provides |
| 701 | definitions that are useful for examining lisp objects. Therefore, |
| 702 | the following tips are mainly of interest when using MSVC. |
| 703 | |
| 704 | The output from debug_print is sent to stderr, and to the debugger |
| 705 | via the OutputDebugString routine. The output sent to stderr should |
| 706 | be displayed in the console window that was opened when the |
| 707 | emacs.exe executable was started. The output sent to the debugger |
| 708 | should be displayed in its "Debug" output window. |
| 709 | |
| 710 | When you are in the process of debugging Emacs and you would like to |
| 711 | examine the contents of a Lisp_Object variable, pop up the QuickWatch |
| 712 | window (QuickWatch has an eyeglass symbol on its button in the |
| 713 | toolbar). In the text field at the top of the window, enter |
| 714 | debug_print(<variable>) and hit return. For example, start and run |
| 715 | Emacs in the debugger until it is waiting for user input. Then click |
| 716 | on the Break button in the debugger to halt execution. Emacs should |
| 717 | halt in ZwUserGetMessage waiting for an input event. Use the Call |
| 718 | Stack window to select the procedure w32_msp_pump up the call stack |
| 719 | (see below for why you have to do this). Open the QuickWatch window |
| 720 | and enter debug_print(Vexec_path). Evaluating this expression will |
| 721 | then print out the contents of the lisp variable exec-path. |
| 722 | |
| 723 | If QuickWatch reports that the symbol is unknown, then check the call |
| 724 | stack in the Call Stack window. If the selected frame in the call |
| 725 | stack is not an Emacs procedure, then the debugger won't recognize |
| 726 | Emacs symbols. Instead, select a frame that is inside an Emacs |
| 727 | procedure and try using debug_print again. |
| 728 | |
| 729 | If QuickWatch invokes debug_print but nothing happens, then check the |
| 730 | thread that is selected in the debugger. If the selected thread is |
| 731 | not the last thread to run (the "current" thread), then it cannot be |
| 732 | used to execute debug_print. Use the Debug menu to select the current |
| 733 | thread and try using debug_print again. Note that the debugger halts |
| 734 | execution (e.g., due to a breakpoint) in the context of the current |
| 735 | thread, so this should only be a problem if you've explicitly switched |
| 736 | threads. |
| 737 | |
| 738 | \f |
| 739 | This file is part of GNU Emacs. |
| 740 | |
| 741 | GNU Emacs is free software: you can redistribute it and/or modify |
| 742 | it under the terms of the GNU General Public License as published by |
| 743 | the Free Software Foundation, either version 3 of the License, or |
| 744 | (at your option) any later version. |
| 745 | |
| 746 | GNU Emacs is distributed in the hope that it will be useful, |
| 747 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 748 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 749 | GNU General Public License for more details. |
| 750 | |
| 751 | You should have received a copy of the GNU General Public License |
| 752 | along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. |