libtool: Cygwin to MinGW Cross

1 
1 15.3.7.6 Cygwin to MinGW Cross
1 ..............................
1 
1 There are actually three different scenarios that could all legitimately
1 be called a "Cygwin to MinGW" cross compile.  The current (and standard)
1 definition is when there is a compiler that produces native Windows
1 libraries and applications, but which itself is a Cygwin application,
1 just as would be expected in any other cross compile setup.
1 
1    However, historically there were two other definitions, which we will
1 refer to as the _fake_ one, and the _lying_ one.
1 
1    In the _fake_ Cygwin to MinGW cross compile case, you actually use a
1 native MinGW compiler, but you do so from within a Cygwin environment:
1 
1      export PATH="/c/MinGW/bin:${PATH}"
1      configure --build=i686-pc-cygwin \
1      	--host=mingw32 \
1      	NM=/c/MinGW/bin/nm.exe
1 
1    In this way, the build system "knows" that you are cross compiling,
1 and the file name conversion logic will be used.  However, because the
1 tools ('mingw32-gcc', 'nm', 'ar') used are actually native Windows
1 applications, they will not understand any Cygwin (that is, Unix-like)
1 absolute file names passed as command line arguments (and, unlike MSYS,
1 Cygwin does not automatically convert such arguments).  However, so long
1 as only relative file names are used in the build system, and
1 non-Windows-supported Unix idioms such as symlinks and mount points are
1 avoided, this scenario should work.
1 
1    If you must use absolute file names, you will have to force Libtool
1 to convert file names for the toolchain in this case, by doing the
1 following before you run configure:
1 
1      export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
1 
1    In the _lying_ Cygwin to MinGW cross compile case, you lie to the
1 build system:
1 
1      export PATH="/c/MinGW/bin:${PATH}"
1      configure --build=i686-pc-mingw32 \
1      	--host=i686-pc-mingw32 \
1      	--disable-dependency-tracking
1 
1 and claim that the build platform is MinGW, even though you are actually
1 running under _Cygwin_ and not MinGW. In this case, libtool does _not_
1 know that you are performing a cross compile, and thinks instead that
1 you are performing a native MinGW build.  However, as described in
1 (⇒Native MinGW File Name Conversion), that scenario triggers an
1 "MSYS to Windows" file name conversion.  This, of course, is the wrong
1 conversion since we are actually running under Cygwin.  Also, the
1 toolchain is expecting Windows file names (not Cygwin) but unless told
1 so Libtool will feed Cygwin file names to the toolchain in this case.
1 To force the correct file name conversions in this situation, you should
1 do the following _before_ running configure:
1 
1      export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
1      export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
1 
1    Note that this relies on internal implementation details of libtool,
1 and is subject to change.  Also, '--disable-dependency-tracking' is
1 required, because otherwise the MinGW GCC will generate dependency files
1 that contain Windows file names.  This, in turn, will confuse the Cygwin
1 'make' program, which does not accept Windows file names:
1 
1      Makefile:1: *** target pattern contains no `%'.  Stop.
1 
1    There have also always been a number of other details required for
1 the _lying_ case to operate correctly, such as the use of so-called
1 "identity mounts":
1 
1      # CYGWIN-ROOT/etc/fstab
1      D:/foo    /foo     some_fs binary 0 0
1      D:/bar    /bar     some_fs binary 0 0
1      E:/grill  /grill   some_fs binary 0 0
1 
1    In this way, top-level directories of each drive are available using
1 identical names within Cygwin.
1 
1    Note that you also need to ensure that the standard Unix directories
1 (like '/bin', '/lib', '/usr', '/etc') appear in the root of a drive.
1 This means that you must install Cygwin itself into the 'C:/' root
1 directory (or 'D:/', or 'E:/', etc)--instead of the recommended
1 installation into 'C:/cygwin/'.  In addition, all file names used in the
1 build system must be relative, symlinks should not be used within the
1 source or build directory trees, and all '-M*' options to 'gcc' except
1 '-MMD' must be avoided.
1 
1    This is quite a fragile setup, but it has been in historical use, and
1 so is documented here.
1