Building and Installing Emacs on MS-Windows using the MSYS and MinGW tools Copyright (C) 2013-2021 Free Software Foundation, Inc. See the end of the file for license conditions. The MSYS/MinGW build described here is supported on versions of Windows starting with Windows XP and newer. Building on Windows 2000 and Windows 9X is not supported (but the Emacs binary produced by this build will run on Windows 9X and newer systems). Do not use this recipe with Cygwin. For building on Cygwin, use the normal installation instructions, ../INSTALL. For building Emacs using the MinGW64/MSYS2 toolchain, see the instructions in the file INSTALL.W64 in this directory. * For the brave (a.k.a. "impatient"): For those who have a working MSYS/MinGW development environment and are comfortable with running Posix configure scripts, here are the concise instructions for configuring and building the native Windows binary of Emacs with these tools: 0. Start the MSYS Bash window. Everything else below is done from that window's Bash prompt. 0a. If you are building from the development trunk (as opposed to a release tarball), produce the configure script, by typing from the top-level Emacs source directory: ./autogen.sh 1. If you want to build Emacs outside of the source tree (recommended), create the build directory and chdir there. 2. Invoke the configure script: - If you are building outside the source tree: /PATH/TO/EMACS/SOURCE/TREE/configure --prefix=PREFIX ... - If you are building in-place, i.e. inside the source tree: ./configure --prefix=PREFIX ... It is always preferable to use --prefix to configure Emacs for some specific location of its installed tree; the default /usr/local is not suitable for Windows (see the detailed instructions for the reasons). The prefix must be absolute. You can pass other options to the configure script. Here's a typical example (for an in-place debug build): ./configure --prefix=/d/usr/emacs --enable-checking='yes,glyphs' \ CFLAGS='-O0 -g3' 3. After the configure script finishes, it should display the resulting configuration. After that, type make Use "make -j N" if your MSYS Make supports parallel execution; the build will take significantly less time in that case. Here N is the number of simultaneous parallel jobs; use the number of the cores on your system. 4. Install the produced binaries: make install If you want the installation tree to go to a place that is different from the one specified by --prefix, say make install prefix=/where/ever/you/want That's it! If these short instructions somehow fail, read the rest of this file. * Installing Git for Windows Skip this section if you already have Git installed and configured, or if you are building from the release tarball, not from the development repository. Git for Windows is available from this download page: https://github.com/git-for-windows/git/releases That page offers both 32-bit and 64-bit installations; pick the one suitable for your OS. In general, we recommend to install a 64-bit Git if you have a 64-bit Windows system; the 32-bit Git will run on 64-bit Windows just fine, but might run into memory problems where the 64-bit Git won't. During Git installation, be sure to select the "Checkout as-is, commit as-is" option from the "Configure line ending conversions" dialog. Otherwise, Git will convert text files to DOS-style CRLF end-of-line (EOL) format, which will cause subtle problems when building Emacs, because MSYS tools (see below) used to build Emacs use binary file I/O that preserves the CR characters that get in the way of some text-processing tools, like 'makeinfo' and the commands invoked by the autogen.sh script. If you already have Git installed and configured with some other EOL conversion option, you will need to reconfigure it, removing the following variables from all of your .gitconfig files: core.eol core.safecrlf core.autocrlf If you cloned the Emacs directory before changing these config variables, you will have to delete the repository and re-clone it after the change. The instructions for cloning the Emacs repository can be found on the Emacs's Savannah project page: https://savannah.gnu.org/projects/emacs * Installing MinGW and MSYS Make sure you carefully read the following two sections in their entirety and install/configure the various packages as instructed. A correct installation makes all the rest almost trivial; a botched installation will likely make you miserable for quite some time. There are two alternatives to installing MinGW + MSYS: using the GUI installer, called mingw-get, provided by the MinGW project, or manual installation. The next two sections describe each one of these. ** Installing MinGW and MSYS using mingw-get A nice installer, called mingw-get, is available for those who don't like to mess with manual installations. You can download it from here: https://sourceforge.net/projects/mingw/files/Installer/mingw-get/ (This installer only supports packages downloaded from the MinGW site; for the rest you will still need the manual method.) After installing mingw-get, invoke it to install the packages that are already selected by default on the "Select Components" screen of its wizard. After that, use "mingw-get install PACKAGE" to install the following additional packages: . msys-base . mingw-developer-toolkit When the installation ends, perform the post-installation steps described on this page of the MinGW site: http://www.mingw.org/wiki/Getting_Started in the "After Installing You Should ..." section. These steps are important for making your installation complete, and in particular will produce a desktop shortcut for running the MSYS Bash shell, from which you will configure and build Emacs. Once you've made the shortcut, double-click on it to open the MSYS Bash shell window, where you will proceed with the rest of these instructions. In addition, we suggest to modify your system-wide Path variable to include the 'bin' subdirectory of your top-level MinGW installation directory, the one you specified to mingw-get ("C:\MinGW" by default). This will allow you to invoke the MinGW development tools, like GCC, from the Windows cmd.exe shell windows or from other Windows programs (including Emacs, after you build and install it). (We recommend that you refrain from installing the MSYS Texinfo package, which is part of msys-base, because it might produce mixed EOL format when installing Info files. Instead, install the MinGW port of Texinfo, see the ezwinports URL below. To uninstall the MSYS Texinfo, after installing it as part of msys-base, invoke the command "mingw-get remove msys-texinfo", or mark "msys-texinfo" for removal in the mingw-get GUI, then select Installation->Apply Changes.) (Similarly, we recommend to refrain from installing the MinGW Autoconf package; instead, install its MSYS build available from the ezwinports site, see below.) At this point, you should be ready to configure and build Emacs in its basic configuration. Skip to the "Generating the configure script" section for the build instructions. If you want to build it with image support and other optional libraries, read about the optional libraries near the end of this document, before you start the build. Also, consider installing additional MinGW packages that are required/recommended, especially if you are building from the development repository, as described in the next section. ** Installing MinGW and MSYS manually *** MinGW You will need to install the MinGW port of GCC and Binutils, and the MinGW runtime and Windows API distributions, to compile Emacs. You can find these on the MinGW download/Base page: https://sourceforge.net/projects/mingw/files/MinGW/Base/ In general, install the latest stable versions of the following MinGW packages from that page: gcc, binutils, mingw-rt, w32api. You only need the 'bin' and the 'dll' tarballs of each of the above. MinGW packages are distributed as .tar.lzma compressed archives. To install the packages manually, we recommend to use the Windows port of the 'bsdtar' program to unpack the tarballs. 'bsdtar' is available as part of the 'libarchive' package from here: http://sourceforge.net/projects/ezwinports/files/ The recommended place to install these packages is a single tree starting from some directory on a drive other than the system drive C:. A typical example would be D:\usr, with D:\usr\bin holding the binaries and DLLs (should be added to your Path environment variable), D:\usr\include holding the include files, D:\usr\lib holding the static and import libraries, D:\usr\share holding docs, message catalogs, and package-specific subdirectories, etc. Having all the headers and libraries in a single place will greatly reduce the number of -I and -L flags you will have to pass to the configure script (see below), as these files will be right where the compiler expects them. We specifically do NOT recommend installing packages below "C:\Program Files" or "C:\Program Files (x86)". These directories are protected on versions of Windows from Vista and on, and you will have difficulties updating and maintaining your installation later, due to UAC elevation prompts, file virtualization, etc. You *have* been warned! Additional MinGW packages are required/recommended, especially if you are building from the development repository: . Texinfo (needed to produce the Info manuals when building from the repository, and for "make install") Available from http://sourceforge.net/projects/ezwinports/files/. . pkg-config (invoked by the configure script to look for optional packages) Available from http://sourceforge.net/projects/ezwinports/files/. . gzip (needed to compress files during "make install") Available from http://gnuwin32.sourceforge.net/packages/gzip.htm. Each package might list other packages as prerequisites on its download page (under "Runtime requirements"); download those as well. (Using the mingw-get installer will fetch those prerequisites automatically for you.) A missing prerequisite will manifest itself by the program failing to run and presenting a pop-up dialog that states the missing or incompatible DLL; be sure to find and install these missing DLLs. Once you think you have MinGW installed, test the installation by building a trivial "hello, world!" program, and make sure that it builds without any error messages and the binary works when run. *** MSYS You will need a reasonably full MSYS installation. MSYS is an environment needed to run the Posix configure scripts and the resulting Makefile's, in order to produce native Windows binaries using the MinGW compiler and runtime libraries. Here's the list of MSYS packages that are required: . All the packages from the MSYS Base distribution, listed here: https://sourceforge.net/projects/mingw/files/MSYS/Base/ . Additional packages listed below, from the MSYS Extension distribution here: https://sourceforge.net/projects/mingw/files/MSYS/Extension/ - flex - bison - m4 - perl - mktemp These should only be needed if you intend to build development versions of Emacs from the repository. . Additional package (needed only if building from the repository): Autoconf. It is available from here: http://sourceforge.net/projects/ezwinports/files/autoconf-2.65-msys-bin.zip/download MSYS packages are distributed as .tar.lzma compressed archives. To install the packages manually, we recommend to use the Windows port of the 'bsdtar' program, already mentioned above. MSYS packages should be installed in a separate tree from MinGW. For example, use D:\MSYS or D:\usr\MSYS as the top-level directory from which you unpack all of the MSYS packages. After installing Autoconf, make sure any of the *.m4 files you might have in your MinGW installation also exist in the MSYS installation tree, in the share/aclocal directory. Those *.m4 files which exist in the MinGW tree, but not in the MSYS tree should be copied there. If/when you are confident in your MinGW/MSYS installation, and want to speed up the builds, we recommend installing a pre-release version of Make from here: https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ These are snapshot builds of many packages, but you only need make.exe from there. The advantage of this make.exe is that it supports parallel builds, so you can use "make -j N" to considerably speed up your builds. Several users reported that MSYS 1.0.18 causes Make to hang in parallel builds. If you bump into this, we suggest to downgrade to MSYS 1.0.17, which doesn't have that problem. For each of these packages, install the 'bin' and 'dll' tarballs of their latest stable releases. If there's an 'ext' tarball (e.g., msysCORE and Coreutils have it), download and install those as well. Each package might list other packages as prerequisites on its download page (under "Runtime requirements"); download those as well. (Using the mingw-get installer will fetch those prerequisites automatically for you.) A missing prerequisite will manifest itself by the program failing to run and presenting a pop-up dialog that states the missing or incompatible DLL; be sure to find and install these missing DLLs. Do NOT add the MSYS bin directory to your Windows Path! Only the MinGW bin directory should be on Path. When you install MSYS, it creates a shortcut on your desktop that invokes the MSYS Bash shell in a Command Prompt window; that shell is already set up so that the MSYS bin directory is on PATH ahead of any other directory. Thus, Bash will find MSYS executables first, which is exactly what you need. * Starting the MSYS Bash shell For most reliable and predictable results, we recommend to start Bash by clicking the "MSYS" icon on your desktop. That icon is created when you install MSYS, and using it is the official way of running the MSYS tools. For other methods of starting the shell, make sure Bash is invoked with the "--login" command-line switch. When the shell window opens and you get the shell prompt, change to the directory where you intend to build Emacs. At this point, you are ready to build Emacs in its basic configuration. If you want to build it with image support and other optional libraries, read about that near the end of this document. * Generating the configure script If you are building a release or pretest tarball, skip this section, because the configure script is already present in the tarball. To build a development snapshot from the Emacs repository, you will first need to generate the configure script and a few other auto-generated files. To generate the configure script, type this at the MSYS Bash prompt from the top-level directory of the Emacs source tree: ./autogen.sh If successful, this command should produce the following output: $ ./autogen.sh Checking whether you have the necessary tools... (Read INSTALL.REPO for more details on building Emacs) Checking for autoconf (need at least version 2.65) ... ok Your system has the required tools. Building aclocal.m4 ... Running 'autoreconf -fi -I m4' ... You can now run './configure'. If the script fails because it cannot find Git, you will need to arrange for the MSYS Bash's PATH to include the Git's 'bin' subdirectory, where there's the git.exe executable. * Configuring Emacs for MinGW: Now it's time to run the configure script. You can do that either from a separate build directory that is outside of the Emacs source tree (recommended), or from inside the source tree. The former is recommended because it allows you to have several different builds, e.g., an optimized build and an unoptimized one, of the same revision of the source tree; the source tree will be left in its pristine state, without any build products. You invoke the configure script like this: /PATH/TO/EMACS/SOURCE/TREE/configure --prefix=PREFIX ... or, if you are building in-place, i.e. inside the source tree: ./configure --prefix=PREFIX ... Here PREFIX is the place where you eventually want to install Emacs once built, e.g. /d/usr. We recommend to always use --prefix when building Emacs on Windows, because the default '/usr/local' is not appropriate for Windows: it will be mapped by MSYS to something like C:\MSYS\local, and it will defeat the purpose of PREFIX, which is to install programs in a single coherent tree resembling Posix systems. Such a single-tree installation makes sure all the other programs and packages ported from GNU or Unix systems will work seamlessly together. Where exactly is the root of that tree on your system is something only you, the user who builds Emacs, can know, and the Emacs build process cannot guess, because usually there's no '/usr/local' directory on any drive on Windows systems. Do NOT use Windows-style x:/foo/bar file names on the configure script command line; use the MSYS-style /x/foo/bar instead. Using Windows-style file names was reported to cause subtle and hard to figure out problems during the build. This applies both to the command switches, such as --prefix=, and to the absolute file name of 'configure', if you are building outside of the source tree. You can pass additional options to the configure script, for the full list type ./configure --help As explained in the help text, you may need to tell the script what are the optional flags to invoke the compiler. This is needed if some of your headers and libraries, e.g., those belonging to optional image libraries, are installed in places where the compiler normally doesn't look for them. (Remember that advice above to avoid such situations? here's is where you will start paying for disregarding that recommendation.) For example, if you have libpng headers in C:\emacs\libs\libpng-1.2.37-lib\include and jpeg library headers in C:\emacs\libs\jpeg-6b-4-lib\include, you will need to say something like this: CPPFLAGS='-I/c/emacs/libs/libpng-1.2.37-lib/include -I/c/emacs/libs/jpeg-6b-4-lib/include' ./configure --prefix=PREFIX which is quite a mouth-full, especially if you have more directories to specify... Perhaps you may wish to revisit your installation decisions now. If you have a global site-lisp directory from previous Emacs installation, and you want Emacs to continue using it, specify it via the --enable-locallisppath switch to 'configure', like this: ./configure --prefix=PREFIX --enable-locallisppath="/d/usr/share/emacs/VERSION/site-lisp:/d/wherever/site-lisp" Use the normal MSYS /d/foo/bar style to specify directories by their absolute file names. A few frequently used options are needed when you want to produce an unoptimized binary with runtime checks enabled: ./configure --prefix=PREFIX --enable-checking='yes,glyphs' \ CFLAGS='-O0 -g3' Once invoked, the configure script will run for some time, and, if successful, will eventually produce a summary of the configuration similar to this: Configured for 'i686-pc-mingw32'. Where should the build process find the source code? /path/to/emacs/sources What compiler should emacs be built with? gcc -std=gnu99 -O0 -g3 Should Emacs use the GNU version of malloc? no (The GNU allocators don't work with this system configuration.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? yes What window system should Emacs use? w32 What toolkit should Emacs use? none Where do we find X Windows header files? NONE Where do we find X Windows libraries? NONE Does Emacs use -lXaw3d? no Does Emacs use -lXpm? yes Does Emacs use -ljpeg? yes Does Emacs use -ltiff? yes Does Emacs use a gif library? yes Does Emacs use a png library? yes Does Emacs use -lrsvg-2? yes Does Emacs use cairo? no Does Emacs use -llcms2? yes Does Emacs use imagemagick? no Does Emacs support sound? no Does Emacs use -lgpm? no Does Emacs use -ldbus? no Does Emacs use -lgconf? no Does Emacs use GSettings? no Does Emacs use a file notification library? yes (w32) Does Emacs use access control lists? yes Does Emacs use -lselinux? no Does Emacs use -lgnutls? yes Does Emacs use -lxml2? yes Does Emacs use -lfreetype? no Does Emacs use HarfBuzz? yes Does Emacs use -lm17n-flt? no Does Emacs use -lotf? no Does Emacs use -lxft? no Does Emacs use -lsystemd? no Does Emacs use -ljansson? yes Does Emacs use the GMP library? yes Does Emacs directly use zlib? yes Does Emacs have dynamic modules support? yes Does Emacs use toolkit scroll bars? yes Does Emacs support Xwidgets? no Does Emacs have threading support in lisp? yes Does Emacs support the portable dumper? yes Does Emacs support the legacy unexec dumping? no Which dumping strategy does Emacs use? pdumper You are almost there, hang on. If the output is significantly different, or if configure finishes prematurely and displays some error message, you should examine the configuration log in config.log and find the reason for the failure. Once you succeeded in configuring Emacs, and just want to rebuild it after updating your local repository from the main repository, you don't need to re-run the configure script manually, unless you want to change the configure-time options. Just typing "make" will re-run configure if necessary with the exact same options you specified originally, and then go on to invoking Make, described below. * Running Make. This is simple: just type "make" and sit back, watching the fun. If you installed a snapshot build of Make, the build will be much faster if you type "make -j N" instead, where N is the number of independent processing units on your machine. E.g., on a core i7 system try using N of 6 or even 8. (If this hangs, see the notes above about downgrading to MSYS 1.0.17.) When Make finishes, you can install the produced binaries: make install or, if you want the installed tree to go in a place different from the configured one, type make install prefix=WHEREVER Congrats! You have built and installed your own Emacs! * Make targets The following make targets may be used by users building the source distribution, or users who have checked out of the repository after an initial bootstrapping. make Builds Emacs from the available sources and pre-compiled lisp files. make install Installs the built programs and the auxiliary files. make clean Removes object and executable files produced by the build process in the current configuration. After "make clean", you can rebuild with the same configuration using make. useful when you want to be sure that all of the products are built from coherent sources. make distclean In addition to the files removed by make clean, this also removes Makefiles and other generated files to get back to the state of a freshly unpacked source distribution. After make distclean, it is necessary to run the configure script followed by "make", in order to rebuild. The following targets are intended only for use with the repository sources. make bootstrap Removes all the auto-generated files and all the *.elc byte-compiled files, and builds Emacs from scratch. Useful when some change in basic Emacs functionality makes byte compilation of updated files fail. make maintainer-clean Removes everything that can be recreated, including compiled Lisp files, to get back to the state of a fresh repository tree. After make maintainer-clean, it is necessary to run configure and "make" or "make bootstrap" to rebuild. Occasionally it may be necessary to run this target after an update. * Optional image library support In addition to its "native" image formats (pbm and xbm), Emacs can handle other image types: xpm, tiff, gif, png, jpeg and experimental support for svg. To build Emacs with support for them, the corresponding headers must be in the include path and libraries should be where the linker looks for them, when the configure script is run. If needed, this can be set up using the CPPFLAGS and CFLAGS variable specified on the configure command line. The configure script will report whether it was able to detect the headers and libraries. 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.) Note that any file path passed to the compiler or linker must use forward slashes, or double each backslash, as that is how Bash works. If the configure script finds the necessary headers and libraries, but they are for some reason incompatible, or if you want to omit support for some image library that is installed on your system for some other reason, use the --without-PACKAGE option to configure, such as --without-gif to omit GIF, --without-tiff to omit TIFF, etc. Passing the --help option to the configure script displays all of the supported --without-PACKAGE options. 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 `dynamic-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 accessible and that the binaries are compatible (for example, that they were built with the same compiler). To support XPM images (required for color tool-bar icons), you will need the libXpm library. It is available from the ezwinports site, http://sourceforge.net/projects/ezwinports/files/ and from https://ftp.gnu.org/gnu/emacs/windows/. For PNG images, we recommend to use versions 1.4.x and later of libpng, because previous versions had security issues. You can find precompiled libraries and headers on the ezwinports site and on ftp.gnu.org. Versions 1.4.0 and later of libpng are binary incompatible with earlier versions, so Emacs will only look for libpng libraries which are compatible with the version it was compiled against. That version is given by the value of the Lisp variable `libpng-version'; e.g., 10403 means version 1.4.3. The variable `dynamic-library-alist' is automatically set to name only those DLL names that are known to be compatible with the version given by `libpng-version'. If PNG support does not work for you even though you have the support DLL installed, check the name of the installed DLL against `dynamic-library-alist' and the value of `libpng-version', and download compatible DLLs if needed. For GIF images, we recommend to use versions 5.0.0 or later of giflib, as it is much enhanced wrt previous versions. You can find precompiled binaries and headers for giflib on the ezwinports site, http://sourceforge.net/projects/ezwinports/files/ and on https://ftp.gnu.org/gnu/emacs/windows/. Version 5.0.0 and later of giflib are binary incompatible with previous versions (the signatures of several functions have changed), so Emacs will only look for giflib libraries that are compatible with the version it was compiled against. Similar to libpng, that version is given by the value of the Lisp variable `libgif-version'; e.g., 50005 means version 5.0.5. The variable `dynamic-library-alist' is automatically set to name only those DLL libraries that are known to be compatible with the version given by `libgif-version'. For JPEG images, you will need libjpeg 6b or later, which will be called libjpeg-N.dll, jpeg62.dll, libjpeg.dll, or jpeg.dll. You can find these on the ezwinports site and on ftp.gnu.org. TIFF images require libTIFF 3.0 or later, which will be called libtiffN.dll or libtiff-N.dll or libtiff.dll. These can be found on the ezwinports site. Pre-built versions of librsvg and its dependencies can be found here: http://sourceforge.net/projects/ezwinports/files/ This site includes a minimal (as much as possible for librsvg) build of the library and its dependencies; it is also more up-to-date with the latest upstream versions. However, it currently only offers 32-bit builds. For building Emacs, you need to download from this site all of the following *-bin.zip archives: librsvg, gdk-pixbuf, cairo, glib The 'bin' archives on this site include both header files and the libraries needed for building with librsvg and for running Emacs. The librsvg archive includes all the shared libraries needed to run Emacs with SVG support; the other 3 packages are required because the compiler needs to see their header files when building Emacs. https://ftp.gnu.org/gnu/emacs/windows/ More fat ports, from the MSYS2 project. To use librsvg at runtime, ensure that librsvg and its dependencies are on your PATH, or in the same directory as the emacs.exe binary. If you are downloading from the ezwinports site, you only need to install a single archive, librsvg-X.Y.Z-w32-bin.zip, which includes all the dependency DLLs. If you think you've got all the dependencies and SVG support is still not working, check your PATH for other libraries that shadow the ones you downloaded. Libraries of the same name from different sources may not be compatible, this problem was encountered in the past, e.g., with libcroco from gnome.org. If you can see etc/images/splash.svg, then you have managed to get SVG support working. Congratulations for making it through DLL hell to this point. For some SVG images, you'll probably see error messages from Glib about failed assertions, or warnings from Pango about failure to load fonts (installing the missing fonts should fix the latter kind of problems). Problems have been observed in some images that contain text, they seem to be a problem in the Windows port of Pango, or maybe a problem with the way Cairo or librsvg is using it that doesn't show up on other platforms. However, Emacs should not crash due to these issues. If you eventually find the SVG support too unstable to your taste, you can rebuild Emacs without it by specifying the --without-rsvg switch to the configure script. Binaries for the other image libraries can be found on the ezwinports site or at the GnuWin32 project (the latter are generally very old, so not recommended). Note specifically that, due to some packaging snafus in the GnuWin32-supplied image libraries, you will need to download _source_ packages for some of the libraries in order to get the header files necessary for building Emacs with image support. * Optional GnuTLS support To compile with GnuTLS, you will need pkg-config to be installed, as the configure script invokes pkg-config to find out which compiler switches to use for GnuTLS. See above for the URL where you can find pkg-config for Windows. You will also need to install the p11-kit package, which is a dependency of GnuTLS, and its header files are needed for compilation of programs that use GnuTLS. You can find p11-kit on the same site as GnuTLS, see the URL below. If the configure script finds the GnuTLS header files and libraries on your system, Emacs is built with GnuTLS support by default; to avoid that you can pass the argument --without-gnutls. In order to support GnuTLS at runtime, a GnuTLS-enabled Emacs must be able to find the relevant DLLs during startup; failure to do so is not an error, but GnuTLS won't be available to the running session. You can get pre-built binaries (including any required DLL and the header files) at http://sourceforge.net/projects/ezwinports/files/ and on https://ftp.gnu.org/gnu/emacs/windows/. * Optional libxml2 support To compile with libxml2, you will need pkg-config to be installed, as the configure script invokes pkg-config to find out which compiler switches to use for libxml2. See above for the URL where you can find pkg-config for Windows. If the configure script finds the libxml2 header files and libraries on your system, Emacs is built with libxml2 support by default; to avoid that you can pass the argument --without-libxml2. In order to support libxml2 at runtime, a libxml2-enabled Emacs must be able to find the relevant DLLs during startup; failure to do so is not an error, but libxml2 features won't be available to the running session. One place where you can get pre-built Windows binaries of libxml2 (including any required DLL and the header files) is here: http://sourceforge.net/projects/ezwinports/files/ https://ftp.gnu.org/gnu/emacs/windows/ For runtime support of libxml2, you will also need to install the libiconv "development" tarball, because the libiconv headers need to be available to the compiler when you compile with libxml2 support. A MinGW port of libiconv can be found on the MinGW site: http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/ You need the libiconv-X.Y.Z-N-mingw32-dev.tar.lzma tarball from that site. * Optional support for decompressing text Emacs can decompress text if compiled with the zlib library. Prebuilt binaries of zlib DLL (for 32-bit builds of Emacs) are available from the ezwinports site and on ftp.gnu.org; see above for the URLs. (This library is also a prerequisite for several image libraries, so you may already have it; look for zlib1.dll or libz-1.dll.) * Optional support for lcms2 library Emacs can expose some capabilities of the Little CMS color management engine to Lisp programs using the lcms2 library. Prebuilt binaries of lcms2 DLL (for 32-bit builds of Emacs) are available from the ezwinports site and from the MSYS2 project. * Optional support for JSON Emacs can provide built-in support for JSON parsing and serialization using the libjansson library. Prebuilt binaries of the libjansson DLL (for 32-bit builds of Emacs) are available from the ezwinports site and from the MSYS2 project. * Optional support for HarfBuzzz shaping library Emacs supports display of complex scripts and Arabic shaping. The preferred library for that is HarfBuzz; prebuilt binaries are available from the ezwinports site (for 32-bit builds of Emacs) and from the MSYS2 project. If HarfBuzz is not available, Emacs will use the Uniscribe shaping engine that is part of MS-Windows. This file is part of GNU Emacs. GNU Emacs is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see .