MinGW/cross-compiler: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
m (+outdated)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Out of date}}
{{Main article|Building FlightGear - Cross Compiling}}
'''Cross compiling a MinGW FlightGear from Cygwin or Linux'''
'''Cross compiling a MinGW FlightGear from Cygwin or Linux'''


Line 4: Line 8:
FlightGear to the mingw32 (win32 APIs only, no cygwin.dll, etc...)
FlightGear to the mingw32 (win32 APIs only, no cygwin.dll, etc...)
target, *not* how to compile it using the [[MSYS]] command line
target, *not* how to compile it using the [[MSYS]] command line
environment. I presume the user already has either a working linux
environment. I presume the user already has either a working linux
box or cygwin installation.)
box or cygwin installation.)


----
----


First you need to build the MinGW cross compiler tools. (Cygwin users
First you need to build the MinGW cross compiler tools. (Cygwin users
can skip this section and simply install the MinGW environment from
can skip this section and simply install the MinGW environment from
the setup tool) I used the source distributions available from the GNU
the setup tool) I used the source distributions available from the GNU
project instead of the MinGW trees, because the MinGW ones failed to
project instead of the MinGW trees, because the MinGW ones failed to
build in linux. Either should work under Cygwin.
build in linux. Either should work under Cygwin.


I am assuming that your cross compiler tools are going to live in a
I am assuming that your cross compiler tools are going to live in a
directory named "/mingw" Change this as appropriate.
directory named "/mingw" Change this as appropriate.


Remember to put /mingw/bin on your path. Some of the configure
Remember to put /mingw/bin on your path. Some of the configure
scripts notice the --prefix setting and pick the right binaries up by
scripts notice the --prefix setting and pick the right binaries up by
default, but others do not, and end up defaulting to the native
default, but others do not, and end up defaulting to the native
Line 34: Line 38:
Now you need the MinGW C runtime and Win32 libraries and headers,
Now you need the MinGW C runtime and Win32 libraries and headers,
because the compiler cannot build without them (this sounds like a bug
because the compiler cannot build without them (this sounds like a bug
to me...) Download them from the mingw.org site and unpack them into
to me...) Download them from the mingw.org site and unpack them into
the /mingw/mingw32 directory.
the /mingw/mingw32 directory.


Line 41: Line 45:
   tar xfz //w32api-2.5.tar.gz
   tar xfz //w32api-2.5.tar.gz


Now it is time to build gcc (3.3.3 in my case). This works just like
Now it is time to build gcc (3.3.3 in my case). This works just like
the binutils step:
the binutils step:


Line 51: Line 55:


Pick a destination path for your FlightGear installation; I am using
Pick a destination path for your FlightGear installation; I am using
"/fg" here for brevity. You will need to specify this with a
"/fg" here for brevity. You will need to specify this with a
"--prefix=/fg" argument to all configure scripts. Don't forget.
"--prefix=/fg" argument to all configure scripts. Don't forget.


For "native" builds many people use the /usr/local default, but for
For "native" builds many people use the /usr/local default, but for
Line 66: Line 70:


You will want to install "SDK" headers and libraries for OpenAL, SDL,
You will want to install "SDK" headers and libraries for OpenAL, SDL,
pthread, and zlib. The goal here is to get header files, lib*.a
pthread, and zlib. The goal here is to get header files, lib*.a
static libraries, and (if needed) runtime DLLs for them installed to
static libraries, and (if needed) runtime DLLs for them installed to
the appropriate place: the *.a libraries go in /fg/lib, DLLs in
the appropriate place: the *.a libraries go in /fg/lib, DLLs in
Line 79: Line 83:
The zlib library (source is packaged with SimGear) has a rather
The zlib library (source is packaged with SimGear) has a rather
primitive non-standard configure script that simply doesn't work for
primitive non-standard configure script that simply doesn't work for
building with a cross compiler or outside a Unix-like environment. I
building with a cross compiler or outside a Unix-like environment. I
built it (just three files: libz.a, zlib.h, zconf.h) by hand. It
built it (just three files: libz.a, zlib.h, zconf.h) by hand. It
''may'' be possible to use the zlib implementation that ships with
''may'' be possible to use the zlib implementation that ships with
cygwin with a MinGW build; whether it works or not depends on whether
cygwin with a MinGW build; whether it works or not depends on whether
Line 86: Line 90:


SDL has a nicely packaged mingw32 development tarball on their website
SDL has a nicely packaged mingw32 development tarball on their website
(www.libsdl.org). You can simply unpack this under /fg if you like.
(www.libsdl.org). You can simply unpack this under /fg if you like.
My version eliminates some of the unnecessary files and is somewhat
My version eliminates some of the unnecessary files and is somewhat
smaller, but is otherwise unchanged.
smaller, but is otherwise unchanged.


The Win32 pthread library (http://sources.redhat.com/pthreads-win32)
The Win32 pthread library (http://sources.redhat.com/pthreads-win32)
also distributes pre-compiled libraries. Unfortunately, you will have
also distributes pre-compiled libraries. Unfortunately, you will have
to rename them before using them. They also ship a broken header (no
to rename them before using them. They also ship a broken header (no
joke) which fails when compiled in an autoconf environment where
joke) which fails when compiled in an autoconf environment where
HAVE_CONFIG_H is defined. My version fixes these problems, but is
HAVE_CONFIG_H is defined. My version fixes these problems, but is
otherwise the same library.
otherwise the same library.


OpenAL is the hardest to get working. First, you really want to
OpenAL is the hardest to get working. First, you really want to
install the binary package via the Creative installer (follow link
install the binary package via the Creative installer (follow link
from www.openal.org) in order to take advantage of binary-only vendor
from www.openal.org) in order to take advantage of binary-only vendor
extensions from Creative and NVidia. Second, the SDK is MSVC-only,
extensions from Creative and NVidia. Second, the SDK is MSVC-only,
with no MinGW/Cygwin import libraries and (sigh) no meaningful
with no MinGW/Cygwin import libraries and (sigh) no meaningful
directory structure. I generated libalut.a and libopenal32.a import
directory structure. I generated libalut.a and libopenal32.a import
libraries by hand from the MSVC .lib files. Unless you want to help
libraries by hand from the MSVC .lib files. Unless you want to help
out the OpenAL project by generating a Cygwin/MinGW build environment
out the OpenAL project by generating a Cygwin/MinGW build environment
for them, you'll probably want to use my pre-packaged version.
for them, you'll probably want to use my pre-packaged version.
Line 109: Line 113:
Note that the openal32.dll file is *not* dumped in the /fg/bin
Note that the openal32.dll file is *not* dumped in the /fg/bin
directory; it is intended to be a system-wide library installed by the
directory; it is intended to be a system-wide library installed by the
Creative installer. Also note that the alut.dll library is a separate
Creative installer. Also note that the alut.dll library is a separate
library, not part of openal32.dll.
library, not part of openal32.dll.


So to make a long story short, I put a tarball of "SDK" tarballs up at
So to make a long story short, I put a tarball of "SDK" tarballs up at
http://plausible.org/andy/fgfs-mingw-libs.tar.gz for folks to use. In
http://plausible.org/andy/fgfs-mingw-libs.tar.gz for folks to use. In
side are four tar files (openal, pthread, sdl, zlib). Simply unpack
side are four tar files (openal, pthread, sdl, zlib). Simply unpack
each one you need in the /fg directory.
each one you need in the /fg directory.


----
----


Now you are ready to compile. This part works exactly as you are used
Now you are ready to compile. This part works exactly as you are used
to. Note that it is important to specify --host (the target platform)
to. Note that it is important to specify --host (the target platform)
and --build (the platform on which you are compiling) in order to get
and --build (the platform on which you are compiling) in order to get
the configure script into "cross compilation" mode. If you specify
the configure script into "cross compilation" mode. If you specify
only host, it tries to guess and sometimes gets it wrong (simple .exe
only host, it tries to guess and sometimes gets it wrong (simple .exe
files work on Linux when wine is installed!). Cygwin users should of
files work on Linux when wine is installed!). Cygwin users should of
course replace the build host with "i386-cygwin".
course replace the build host with "i386-cygwin".


Line 141: Line 145:
FlightGear:
FlightGear:


Note here that we can only build in the src directory. The auxilliary
Note here that we can only build in the src directory. The auxilliary
directories tend to be POSIX-only and are not (automatically)
directories tend to be POSIX-only and are not (automatically)
compilable at the moment.
compilable at the moment.
Line 156: Line 160:
   cd /fg/bin
   cd /fg/bin
   mingw32-strip *.exe
   mingw32-strip *.exe
[[Category:Software]]
[[Category:Howto]]

Latest revision as of 18:24, 26 May 2015

This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

1rightarrow.png See Building FlightGear - Cross Compiling for the main article about this subject.


Cross compiling a MinGW FlightGear from Cygwin or Linux

(Initial meta-note: these are instructions for how to compile FlightGear to the mingw32 (win32 APIs only, no cygwin.dll, etc...) target, *not* how to compile it using the MSYS command line environment. I presume the user already has either a working linux box or cygwin installation.)


First you need to build the MinGW cross compiler tools. (Cygwin users can skip this section and simply install the MinGW environment from the setup tool) I used the source distributions available from the GNU project instead of the MinGW trees, because the MinGW ones failed to build in linux. Either should work under Cygwin.

I am assuming that your cross compiler tools are going to live in a directory named "/mingw" Change this as appropriate.

Remember to put /mingw/bin on your path. Some of the configure scripts notice the --prefix setting and pick the right binaries up by default, but others do not, and end up defaulting to the native compiler (trust me, you don't want to spend 20 minutes compiling plib just to discover that you've built a Linux library):

export PATH=/mingw/bin:$PATH

Get the source to GNU binutils (I used version 2.15) and build it:

 ./configure --target=mingw32 --prefix=/mingw
 make
 make install

Now you need the MinGW C runtime and Win32 libraries and headers, because the compiler cannot build without them (this sounds like a bug to me...) Download them from the mingw.org site and unpack them into the /mingw/mingw32 directory.

 cd /mingw/mingw32
 tar xfz //mingw-runtime-3.2.tar.gz
 tar xfz //w32api-2.5.tar.gz

Now it is time to build gcc (3.3.3 in my case). This works just like the binutils step:

 ./configure --target=mingw32 --prefix=/mingw
 make
 make install

Pick a destination path for your FlightGear installation; I am using "/fg" here for brevity. You will need to specify this with a "--prefix=/fg" argument to all configure scripts. Don't forget.

For "native" builds many people use the /usr/local default, but for cross compilation you *must* place the resulting must in a tree by themselves.


Before compiling anything, you will need to install the dependent binary libraries (skip to the end of the section if you are happy with downloading packages I put together and don't want to read the long explanation).

You will want to install "SDK" headers and libraries for OpenAL, SDL, pthread, and zlib. The goal here is to get header files, lib*.a static libraries, and (if needed) runtime DLLs for them installed to the appropriate place: the *.a libraries go in /fg/lib, DLLs in /fg/bin, and headers under /fg/include.

Unfortunately, because the cross compilation environment is more complicated and because MSVC has traditionally been the "standard" build environment, none of these packages are as simple to install as "configure; make; make install" on a linux host, nor are they installable by default with cygwin.

The zlib library (source is packaged with SimGear) has a rather primitive non-standard configure script that simply doesn't work for building with a cross compiler or outside a Unix-like environment. I built it (just three files: libz.a, zlib.h, zconf.h) by hand. It may be possible to use the zlib implementation that ships with cygwin with a MinGW build; whether it works or not depends on whether the different underlying C libraries are sufficiently compatible.

SDL has a nicely packaged mingw32 development tarball on their website (www.libsdl.org). You can simply unpack this under /fg if you like. My version eliminates some of the unnecessary files and is somewhat smaller, but is otherwise unchanged.

The Win32 pthread library (http://sources.redhat.com/pthreads-win32) also distributes pre-compiled libraries. Unfortunately, you will have to rename them before using them. They also ship a broken header (no joke) which fails when compiled in an autoconf environment where HAVE_CONFIG_H is defined. My version fixes these problems, but is otherwise the same library.

OpenAL is the hardest to get working. First, you really want to install the binary package via the Creative installer (follow link from www.openal.org) in order to take advantage of binary-only vendor extensions from Creative and NVidia. Second, the SDK is MSVC-only, with no MinGW/Cygwin import libraries and (sigh) no meaningful directory structure. I generated libalut.a and libopenal32.a import libraries by hand from the MSVC .lib files. Unless you want to help out the OpenAL project by generating a Cygwin/MinGW build environment for them, you'll probably want to use my pre-packaged version.

Note that the openal32.dll file is *not* dumped in the /fg/bin directory; it is intended to be a system-wide library installed by the Creative installer. Also note that the alut.dll library is a separate library, not part of openal32.dll.

So to make a long story short, I put a tarball of "SDK" tarballs up at http://plausible.org/andy/fgfs-mingw-libs.tar.gz for folks to use. In side are four tar files (openal, pthread, sdl, zlib). Simply unpack each one you need in the /fg directory.


Now you are ready to compile. This part works exactly as you are used to. Note that it is important to specify --host (the target platform) and --build (the platform on which you are compiling) in order to get the configure script into "cross compilation" mode. If you specify only host, it tries to guess and sometimes gets it wrong (simple .exe files work on Linux when wine is installed!). Cygwin users should of course replace the build host with "i386-cygwin".

Plib:

 ./configure --host=mingw32 --build=i386-linux --prefix=/fg
 make
 make install

SimGear:

 ./configure --host=mingw32 --build=i386-linux --prefix=/fg
 make
 make install

FlightGear:

Note here that we can only build in the src directory. The auxilliary directories tend to be POSIX-only and are not (automatically) compilable at the moment.

 ./configure --host=mingw32 --build=i386-linux --prefix=/fg --enable-sdl
 cd src
 make
 make install

Finally, if you plan on distributing the resulting files, you will want to strip them to remove the symbol tables (the fgfs.exe file is 62 MB in my build.):

 cd /fg/bin
 mingw32-strip *.exe