15.3.7.6 Cygwin to MinGW Cross

There are actually three different scenarios that could all legitimately be called a “Cygwin to MinGW” cross compile. The current (and standard) definition is when there is a compiler that produces native Windows libraries and applications, but which itself is a Cygwin application, just as would be expected in any other cross compile setup.

However, historically there were two other definitions, which we will refer to as the fake one, and the lying one.

In the fake Cygwin to MinGW cross compile case, you actually use a native MinGW compiler, but you do so from within a Cygwin environment:

export PATH="/c/MinGW/bin:${PATH}"
configure --build=i686-pc-cygwin \
	--host=mingw32 \
	NM=/c/MinGW/bin/nm.exe

In this way, the build system “knows” that you are cross compiling, and the file name conversion logic will be used. However, because the tools (mingw32-gcc, nm, ar) used are actually native Windows applications, they will not understand any Cygwin (that is, Unix-like) absolute file names passed as command line arguments (and, unlike MSYS, Cygwin does not automatically convert such arguments). However, so long as only relative file names are used in the build system, and non-Windows-supported Unix idioms such as symlinks and mount points are avoided, this scenario should work.

If you must use absolute file names, you will have to force Libtool to convert file names for the toolchain in this case, by doing the following before you run configure:

export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32

In the lying Cygwin to MinGW cross compile case, you lie to the build system:

export PATH="/c/MinGW/bin:${PATH}"
configure --build=i686-pc-mingw32 \
	--host=i686-pc-mingw32 \
	--disable-dependency-tracking

and claim that the build platform is MinGW, even though you are actually running under Cygwin and not MinGW. In this case, libtool does not know that you are performing a cross compile, and thinks instead that you are performing a native MinGW build. However, as described in (see section Native MinGW File Name Conversion), that scenario triggers an “MSYS to Windows” file name conversion. This, of course, is the wrong conversion since we are actually running under Cygwin. Also, the toolchain is expecting Windows file names (not Cygwin) but unless told so Libtool will feed Cygwin file names to the toolchain in this case. To force the correct file name conversions in this situation, you should do the following before running configure:

export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32

Note that this relies on internal implementation details of libtool, and is subject to change. Also, --disable-dependency-tracking is required, because otherwise the MinGW GCC will generate dependency files that contain Windows file names. This, in turn, will confuse the Cygwin make program, which does not accept Windows file names:

Makefile:1: *** target pattern contains no `%'.  Stop.

There have also always been a number of other details required for the lying case to operate correctly, such as the use of so-called identity mounts:

# cygwin-root/etc/fstab
D:/foo    /foo     some_fs binary 0 0
D:/bar    /bar     some_fs binary 0 0
E:/grill  /grill   some_fs binary 0 0

In this way, top-level directories of each drive are available using identical names within Cygwin.

Note that you also need to ensure that the standard Unix directories (like ‘/bin’, ‘/lib’, ‘/usr’, ‘/etc’) appear in the root of a drive. This means that you must install Cygwin itself into the ‘C:/’ root directory (or ‘D:/’, or ‘E:/’, etc)—instead of the recommended installation into ‘C:/cygwin/’. In addition, all file names used in the build system must be relative, symlinks should not be used within the source or build directory trees, and all ‘-M*’ options to gcc except ‘-MMD’ must be avoided.

This is quite a fragile setup, but it has been in historical use, and so is documented here.

This document was generated on December 1, 2011 using texi2html 5.0.