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 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.