GnuWin32
If you wish to compile yourself: get the source package <package>-<version>-src.zip. You need GNU Bash, GNU Make and Mingw32 GCC and BinUtils. In these notes it is assumed that you are familiar with Bash, Make and GCC. Win32 implementations of Bash can be found in the CygWin tools, in the Msys tools, and in the DJGPP tools. Win32 implementations of Make can be found in CygWin, Msys, DJGPP, Mingw and on GNU software on Windows 32-bit. CygWin Bash and Make work quite well. Note that, when you mix CygWin or Msys Bash and a native Make, problems may occur because CygWin and Msys have their own way of absolute filenames (for example c:/tools becomes /cygdrive/c/tools in CygWin and /c/tools in Msys).
The configuration and ad hoc changes needed to compile are done in Makefile.mingw; type make -f makefile.mingw at the Bash prompt. General configure options have been set in a config.site; make sure that the environment variable CONFIG_SITE points to this file. If there is no Makefile.mingw, then type ./configure.
When configure has finished, type make. Sometimes you need additional libraries and include files. Usually the line export LIBS = ... and other lines with -l... in Makefile.mingw show which additional libraries are needed. If you have these libraries, then you will also have the include files needed by these libraries. Rarely you need more include files; if on compiling you get an error message about a missing include file, then these might be found somewhere in the CygWin, Msys, or DJGPP distributions, but be careful not to replace any native declarations.
In Makefiles, you may have to change ln -s to cp, or use a version of ln that actually copies instead of making soft links.
More and more packages use LibTool for compiling, linking and installing. When installing into a directory with ~ in its name, it gets confused; so change all occurrences of ~ in LibTool into some other character, e.g. !
There have been reports that GnuWin32 executables have crashed on systems with processors other than Intel, e.g. on systems with an AMD processor. These crashes can be avoided by compiling with options specific to Win32 systems, e.g. by using -mms-bitfields -mcpu=pentium -march=i386 as options to GCC.
Several packages use functions that are standard on Unix, for example for obtaining the user name. Some have Windows equivalents, others don't. You will have to provide a Windows equivalent that does something sensible; usually a dummy that does nothing, also works. Equivalents for several functions are in the LibGw32C library, which is an extension of the Msup and Mstubs libraries.
Packages that contain a library, usually build only a static library (with extension .a). A dynamic link library (DLL) with corresponding import library can be built from this static library with the linker ld, by dlltool or by dllwrap (provided in the Mingw BinUtils collection). The shell scripts a2dll and o2dll show more details.
If a package has originally been configured by means of autoconf (shown by the existence of the file configure.in or configure.ac), then it might be reconfigured to make dynamic libraries, but very often this does not seem to be worth the trouble.
When you have built the DLL, you can rebuild the executables
such that they use the DLL. Delete or rename the executable first.
Since often the Makefile calls the library explicitly (for
example ../.libs/foo.a) rather than with the -L/-l-options
(in the example: -L ../.libs -lfoo), either change the Makefile
or temporarily rename the import library to the name of the
static library. Then run make again.
For libraries that are called in the standard way with -L/-l,
Mingw automatically chooses the import library for the DLL rather
than the static library if the import library has extension .dll.a.
For packages that use LibTool, this will not work, since LibTool then remakes the static library. Instead change in libfoo.la (in the directory just above the .libs directory that contains libfoo.a), the term libfoo.a to libfoo.dll.a, and run make again. In principle, LibTool will build dynamic libraries if the option --enable-shared to configure has been set, but in practice only the latest versions of LibTool can handle this and even then you may still end up with a static library, or with a dll that has a version number attached to its name.
It is possible to create import libraries for use with MSVC and BCC.
Mingw versions 2.95.3-3 and earlier cannot import static data from a DLL in the standard way, i.e. by using the extern declaration. This shows as an auto import warning when linking an executable that uses the DLL: Warning: resolving vvvvv by linking to __imp__vvv (auto-import) where vvv is the name of the static variable. It may also show as an Undefined reference to _nm__vvv or Undefined reference to dllname_dll_a_iname where dllname is the name of the dll to be created. If this occurs you may have to change some include files that declare these static data. Include at the start of the source:
#if defined (BUILD_ddd_DLL) || !defined (__WIN32__)
# define DLL_IMPORT extern
#else
# define DLL_IMPORT __DLL_IMPORT
#endif
Replace extern by DLL_IMPORT in all relevant
places in the include files, and add -DBUILD_ddd_DLL=1,
where ddd indicates the DLL, as flag to the compiler
when compiling code that imports from the DLL.
Versions 2.95.3-4 and higher circumvent this auto-import problem
when the option --enable-auto-import is given to the
linker; for versions 2.95.3-6 and higher this is the default
behaviour, so you need not set the option. Very occasionally you
still get an error message; solve this in the above manner (see
also the documentation of the GNU linker ld, section 2.1.1).
On MS Windows there is a difference between text filemode and binary filemode. Unless you are sure that a file is always a text file, it is best to open it in binary mode; so add "b" to the mode when using fopen and O_BINARY when using open. For O_BINARY to be defined, you may have to include fcntl.h. After a file has been opened, its mode may be changed by calling setmode before any output or input has occurred.
Standard input, output and error can be opened in binary mode by adding
to the beginning of the main program file, or by including stdbin.h. Alternatively, you can compile stdbin.h into a small library and link it to the executable.
Similarly, all other files will be opened in binary mode, even when "b" has not been specified in the mode parameter of fopen, when
is added to the beginning of the main program file, when binmode.h is included, or when binmode.h has been compiled into a library and linked to the executable.
The path separator on Unix is the colon (:) and the directory separator is the forwardslash (/); on MS Windows these are the semicolon (;) and the backslash (\). Filenames with forwardslashes are understood by MS Windows, but you will have to change colons to semicolons when used as path separator. Tests for absolute filenames (on Unix filenames starting with /, on MS Windows filenames starting with x:/ or \\) must also be changed, as well as absolute filenames such as /tmp/..., /usr/..., /dev/..., /etc/.... These filename issues may also occur in shell scripts provided with the package. Often they are also the cause of failure in tests or checks with make test or make check.
Temporary file names may either be hardcoded (/tmp/...) or created with the help of an environment variable, usually TMP or TMPDIR. On Windows, the temporary file directory is Temp or Windows/Temp; and the corresponding environment variable is TEMP. You will have to change the Unix names, set the Unix environment variables, or adapt the source to look also for the Windows environment variable TEMP.
Wildcards on the command-line are expanded by the command-line interpreter. If you wish to disable this filename globbing, then add
to the beginning of the main program file.
On Unix, executables usually are installed into /usr/bin and implementation-independent files, such as configuration and language files, in /usr/share or in /usr/etc, whose names are hard coded in the executable. On MS Windows there is no default location, and instead most packages go into a directory of their own, e.g. E:/Program Files/<package>. Because the name of the implementation-independent directory is hard-coded in the program, packages with implementation-independent files must be installed in their default installation directory, which for GnuWin32 is always C:/Progra~1/<package>.
It is not very difficult to change a program such that it also looks into the implementation-independent directory relative to the directory where the executable is installed; for example, when the program has been installed into D:/Applic/<package>, it looks for its configurations in say C:/Progra~1/<package>/share and when nothing has been found there, it looks in D:/Applic/<package>/share. This solution has been followed in the later ports on GnuWin32, which thus may be installed in any directory provided the subdirectory structure is maintained. Native language support (NLS) has also been adapted in this way. An alternative solution would have been to let the program read an initialization file in its program directory or let it read the registry.