libtool: Cross compiling
1
1 15.3.6 Cross compiling
1 ----------------------
1
1 Most build systems support the ability to compile libraries and
1 applications on one platform for use on a different platform, provided a
1 compiler capable of generating the appropriate output is available. In
1 such cross compiling scenarios, the platform where the libraries or
1 applications are compiled is called the "build platform", while the
1 platform where the libraries or applications are intended to be used or
11 executed is called the "host platform". ⇒The GNU Build System
(automake)GNU Build System, of which libtool is a part, supports cross
1 compiling via arguments passed to the configure script: '--build=...'
1 and '--host=...'. However, when the build platform and host platform
1 are very different, libtool is required to make certain accommodations
1 to support these scenarios.
1
1 In most cases, because the build platform and host platform differ,
1 the cross-compiled libraries and executables can't be executed or tested
1 on the build platform where they were compiled. The testsuites of most
1 build systems will often skip any tests that involve executing such
1 foreign executables when cross-compiling. However, if the build
1 platform and host platform are sufficiently similar, it is often
1 possible to run cross-compiled applications. Libtool's own testsuite
1 often attempts to execute cross-compiled tests, but will mark any
1 failures as _skipped_ since the failure might simply be due to the
1 differences between the two platforms.
1
1 In addition to cases where the host platform and build platform are
1 extremely similar (e.g. 'i586-pc-linux-gnu' and 'i686-pc-linux-gnu'),
1 there is another case where cross-compiled host applications may be
1 executed on the build platform. This is possible when the build
1 platform supports an emulation or API-enhanced environment for the host
1 platform. One example of this situation would be if the build platform
1 were MinGW, and the host platform were Cygwin (or vice versa). Both of
1 these platforms can actually operate within a single Windows instance,
1 so Cygwin applications can be launched from a MinGW context, and vice
1 versa--provided certain care is taken. Another example would be if the
1 build platform were GNU/Linux on an x86 32bit processor, and the host
1 platform were MinGW. In this situation, the Wine
1 (http://www.winehq.org/) environment can be used to launch Windows
1 applications from the GNU/Linux operating system; again, provided
1 certain care is taken.
1
1 One particular issue occurs when a Windows platform such as MinGW,
1 Cygwin, or MSYS is the host or build platform, while the other platform
1 is a Unix-style system. In these cases, there are often conflicts
1 between the format of the file names and paths expected within host
1 platform libraries and executables, and those employed on the build
1 platform.
1
1 This situation is best described using a concrete example: suppose
1 the build platform is GNU/Linux with canonical triplet
1 'i686-pc-linux-gnu'. Suppose further that the host platform is MinGW
1 with canonical triplet 'i586-pc-mingw32'. On the GNU/Linux platform
1 there is a cross compiler following the usual naming conventions of such
1 compilers, where the compiler name is prefixed by the host canonical
1 triplet (or suitable alias). (For more information concerning canonical
DONTPRINTYET 11 triplets and platform aliases, see ⇒Specifying Target Triplets
(autoconf)Specifying Target Triplets. and *noteCanonicalizing:
1DONTPRINTYET 11 triplets and platform aliases, see ⇒Specifying Target Triplets
(autoconf)Specifying Target Triplets. and ⇒Canonicalizing
(autoconf)Canonicalizing.) In this case, the C compiler is named
1 'i586-pc-mingw32-gcc'.
1
1 As described in ⇒Wrapper executables, for the MinGW host
1 platform libtool uses a wrapper executable to set various environment
1 variables before launching the actual program executable. Like the
1 program executable, the wrapper executable is cross-compiled for the
1 host platform (that is, for MinGW). As described above, ordinarily a
1 host platform executable cannot be executed on the build platform, but
1 in this case the Wine environment could be used to launch the MinGW
1 application from GNU/Linux. However, the wrapper executable, as a host
1 platform (MinGW) application, must set the 'PATH' variable so that the
1 true application's dependent libraries can be located--but the contents
1 of the 'PATH' variable must be structured for MinGW. Libtool must use
1 the Wine file name mapping facilities to determine the correct value so
1 that the wrapper executable can set the 'PATH' variable to point to the
1 correct location.
1
1 For example, suppose we are compiling an application in '/var/tmp' on
1 GNU/Linux, using separate source code and build directories:
1
1 /var/tmp/foo-1.2.3/app/ (application source code)
1 /var/tmp/foo-1.2.3/lib/ (library source code)
1 /var/tmp/BUILD/app/ (application build objects here)
1 /var/tmp/BUILD/lib/ (library build objects here)
1
1 Since the library will be built in '/var/tmp/BUILD/lib', the wrapper
1 executable (which will be in '/var/tmp/BUILD/app') must add that
1 directory to 'PATH' (actually, it must add the directory named OBJDIR
1 under '/var/tmp/BUILD/lib', but we'll ignore that detail for now).
1 However, Windows does not have a concept of Unix-style file or directory
1 names such as '/var/tmp/BUILD/lib'. Therefore, Wine provides a mapping
1 from Windows file names such as 'C:\Program Files' to specific
1 Unix-style file names. Wine also provides a utility that can be used to
1 map Unix-style file names to Windows file names.
1
1 In this case, the wrapper executable should actually add the value
1
1 Z:\var\tmp\BUILD\lib
1
1 to the 'PATH'. libtool contains support for path conversions of this
1 type, for a certain limited set of build and host platform combinations.
1 In this case, libtool will invoke Wine's 'winepath' utility to ensure
1 that the correct 'PATH' value is used. ⇒File name conversion.
1