File: libtool.info,  Node: Cygwin to MinGW Cross,  Prev: LT_CYGPATH,  Up: File name conversion

15.3.6.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
(*note 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.