Building FlightGear - Cross Compiling

From FlightGear wiki
Jump to navigation Jump to search
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear 2019.x. 30}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
Started in 05/2015
Description Windows binaries created using a cross compiler on Linux
Maintainer(s) Hamzaalloush and Hooray
Contributor(s) hamzaalloush, FlyHigh (since 05/2015)
Status Under active development as of 06/2016 [1] 70}% completed (compiles & runs OSG/osgEarth examples)


Note  Currently, MXE has OSG 3.4.0, but Simgear uses OSG 3.2.0, and there are build errors (likely resulting from API changes), so I'm reluctant to add in a new application which cannot compile. Besides this, all of Simgear's dependencies are in the main master branch.

-- Flyhigh (talk) Sat Oct 24, 2015 1:46 pm

As of June 10, we are starting to make progress both on the shared and static builds of FlightGear/SimGear dependencies. as for a shared build of Flight Gear itself, a segmentation fault is currently occurring and being investigated. crash information

Note  I'll work on getting the backtraces, but if I recall correctly, they didn't seem too helpful. PortableXDR is used in compiling hdf4; I don't think any of the other downstream libraries (gdal, netcdf, openscenegraph, simgear, flightgear) use it directly. Regarding the segfaults, they're actually happening at the end of "initializing subsystems" and the start of "finalizing subsystems".

-- Flyhigh (talk) 00:05, 8 June 2015 (EDT)

In addition, a 32-bit TerraGear static build has been done, although it still throws up segmentation faults. The patches are applied for Mingw64 compatibility will be reviewed by a TerraGear developer.

We will also investigate adding a means for obtaining useful backtraces in a cross-platform fashion, possibly using either CrashRpt or BreakPad.



Note  As of 11/2015, most patches are being merged upstream (mxe) - so that we won't need to maintain our own branches.

For the sake of simplicity, we are currently focusing on 64 bit static builds without using any optimizations at all (i.e. debug builds), this is also to simplify troubleshooting and testing (i.e. quality of backtraces).

Also, to benefit from parallel builds on multicore systems, we need to review package dependencies to see which packages can be built concurrently, and which dependencies must be built sequentially. Any custom *.mxe files should be written with concurrent builds in mind, as well as supporting both use-cases: static and shared linking (see FlyHigh's for reference).

Task Description Priority People Progress
mxe 32-bit static tool-chain progress of the static mxe i686-w64-mingw32-based tool-chain Stars-1.png Hamzaalloush Done Done
mxe 32-bit shared tool-chain progress of the shared mxe i686-w64-mingw32-based tool-chain Stars-1.png Hamzaalloush & FlyHigh 50}% completed
mxe 64-bit static tool-chain progress of the static mxe x86_64-w64-mingw32-based tool-chain Stars-5.png Hamzaalloush & FlyHigh -saiarcot895 70}% completed
mxe 64-bit shared tool-chain progress of the shared mxe x86_64-w64-mingw32-based tool-chain Stars-5.png Hamzaalloush & FlyHigh -saiarcot895 70}% completed
flightgear specific mxe tool-chain mxe subset/progress of packages neccessary for the flightgear project, rather than the full 367 packages Stars-1.png Hamzaalloush 70}% completed
osg-earth-patched FG there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [1] Stars-5.png Not done Not done
leak checking support add support for leak checking using Address Sanitizer via -fsanitize=address -fno-omit-frame-pointer [2] Stars-3.png ... Not done Not done
ccache explore adding ccache support Stars-2.png Hooray 30}% completed
binary packages provide binary mxe packages (deb/ppa) - see: Stars-2.png mxe devs 60}% completed
VM provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up (e.g. via dmxe/ Stars-2.png Hooray 30}% completed
Superbuild Update the CMake Superbuild to support mxe ?? Stars-0.png Hooray Not done Not done
osg-earth update the Superbuild to support osgEarth priority people Not done Not done
build server get the FlightGear Build Server updated to support mxe-based cross-builds mid-term Jenkins maintainers Not done Not done
Simgear portability ensure Simgear is portable upstream for different platforms. (ex. Mingw64 is a different platform) Stars-5.png core developers Not done Not done


This is a list of dependencies (usually, dedicated *.mk modules for mxe)

Note  All main dependencies (osg,osgearth, simgear, flightgear) will by default be built using -DCMAKE_BUILD_TYPE=DEBUG to ensure that we can easily troubleshoot problems, once all unit tests (demos/examples) of each package build/link and work correctly, the build type for the corresponding package will be promoted to RelWithDbg.

Also, Qt 5 is in MXE, but because the source code has been split into multiple source packages, the "qt5" target just builds all of the Qt 5 components. For Flightgear, I think "qtbase" (and "qtdeclarative", if it uses QML files) is sufficient. Since Qt5 is an optional dependency for a launcher, we will not focus on something that could be achieved equally using another launcher, the purpose of our MXE adventure is to help people troubleshoot and compile faster than nightly without going Windows SDK, but it is definitely "nice-to-have" the QT launcher, so that will have to wait.

Task Merged upstream Build System Description People Progress Done Done autotools provide mxe build scripts for plib Done Done Not done Not done cmake add OpenRTI support Hamzaalloush 30}% completed
optional Not done Not done cmake add support for optional dependencies (probably, separate *.mk files for each) Not done Not done
3rdParty Not done Not done mxe ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone 80}% completed Pending Pending cmake provide mxe build scripts for simgear FlyHigh -saiarcot895 70}% completed support (shared library) Done Done cmake improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) Hamzaalloush & FlyHigh 90}% completed
osg examples/demos Pending Pending cmake ensure that all OSG examples build/link properly via -DBUILD_OSG_EXAMPLES=ON and -DBUILD_OSG_APPLICATIONS=ON 90}% completed Not done Not done cmake add dedicated module for mxe (ensure that the examples are working properly) also see gdal issue discussed at [3] Hamzaalloush 70}% completed Not done Not done cmake provide mxe build script for flightgear FlyHigh -saiarcot895 70}% completed Not done Not done autotools provide mxe build script for breakpad
Windows integration instructions at [4]
Hooray & Hamzaalloush 60}% completed Not done Not done cmake provide mxe build script for sigar -System Information Gatherer And Reporter (cmake based, for better startup/run-time diagnostics on CPU/RAM utilization) Hooray Not done Not done
Makefile SVN support Not done Not done make tailor the MXE Makefile to resolve the commit suffix in file names of SVN snapshot's. specific to SG/FG by using ${PKG} conditionals Hamzaalloush 20}% completed Not done Not done cmake build static monolithic TerraGear (compiles but segfaults) Hamzaalloush 40}% completed


We want to allow Linux-based contributors to easily provide customized FlightGear binaries to Windows end users by cross-compiling FlightGear and all its dependencies (OpenSceneGraph, PLIB, OpenAL, SimGear etc), including support for the new osgEarth mode, developed by poweroftwo.

For the sake of simplicity, we are hoping to provide a toolchain that is compatible with common *nix tools like ccache/distcc to help speed up compilation (especially on multi-core platforms), the focus of the underlying mxe-based tool chain will be building OpenSceneGraph 3.xx based applications like FlightGear and osgEarth. To keep mxe installation straightforward, we may provide deb/ppa packages (possibly using the OpenSuse Build Service) or even set up a VirtualBox appliance with mxe.osg pre-installed and configured for building OSG applications (including SG/FG).

In addition, one challenge frequently encountered on the FlightGear forums is that RCs (release candidates) usually get very little, if any, thorough testing by end users and that Windows-based end-users form the largest share of our users, but most of them are unable to provide action-able bug reports, e.g. due to being unable to provide backtraces or running/using diagnostic tools like gdb, valgrind, google perftools etc.

Given the huge number of Windows based end-users, cross-compiled Windows binaries would ideally provide integrated diagnostics to deal with segfaults, memory leaks and to help with profiling, so that better bug reports can be provided by end-users, without them having to be developers, and without having to build FG from source.

This is also an issue identified by other developers (e.g. TerraGear). And it was one of the original reasons for integrating support for CrashRpt.

Given the focus on creating binaries specifically for Windows end-users, we are also investigating options for patching FlightGear to provide better diagnostic tools if necessary, especially invovling Google BreakPad for providing backtraces:

Cquote1.png Is there somewhere an option to get a stacktrace when FG crashes?
— Necolatis (Sat Feb 16). Re: FG Crash reported to Microsoft..
(powered by Instant-Cquotes)
Cquote1.png a number of users have asked for such a feature, I have added the idea to our "Lessons learned" section in the wiki for 2.10.0: Release_Plan#2.10
— Hooray (Mon Feb 18). Re: FG Crash reported to Microsoft.  .
(powered by Instant-Cquotes)
Cquote1.png BreakPad would be useful in getting higher quality crash reports
— zakalawe (Sat Oct 19). Re: Loading forever: "loading navigation data".
(powered by Instant-Cquotes)
Cquote1.png regarding backtraces/stacktraces, these are obviously difficult to provide for people who are not developers - which is why we talked about adding a corresponding feature to FG by linking in a "backtrace library" like BreakPad: ... 42#p176669
— Hooray (Tue Feb 19). Re: Release 2.10 - not fixed bugs.
(powered by Instant-Cquotes)
Cquote1.png If we could teach the build server to build fgfs binaries with Google BreakPad support, it should be much easier for Windows-based users to provide the required info without having to build from source. I don't have a Windows system here, but I can help with the Linux-integration.
— Hooray (Sat Oct 19). Re: Loading forever: "loading navigation data".
(powered by Instant-Cquotes)
Cquote1.png we should probably consider adding a simple strack trace signal handler via backtrace() on *nix platforms (i.e. Mac and Linux), or just by linking in libSegFault.a

And we already have optional Google PerfTools support, so we could just as well support Google BreakPad, too - which would give us this functionality for all supported FG platforms (used by Mozilla, Chrome etc): ... thBreakpad

— Hooray (Fri Feb 08). Re: [Windows] FlightGear RC1.
(powered by Instant-Cquotes)
Cquote1.png I noticed the open source crash reporting software Breakpad being worked on by Mozilla/Google. I am wondering if this is something could be used to aid FlightGear development.
— saturn5 (Mon Aug 11).  open source crash reporter.
(powered by Instant-Cquotes)
Cquote1.png What caught my attention is that it could make it easier to report and see crashes. There is a Socorro web server software connected to breakpad development.

For instance, if somone releases a new model, all the errors people have with it could be reported to the server, then they could go and look see how stable it is. Then it would be easier to see if it is a problem with FG, or the new model. So a model developer could log on and see just the crashes that happen with the new aircraft (or a new FDM, etc.). Here is some more about breakpad; down at the bottom it show the thing for looking at crash reports.<br/

— saturn5 (Sat Aug 16). Re: .
(powered by Instant-Cquotes)


anyone who cares about [..] free-as-in-speech is invited and encouraged to work on mingw support, which used to work and James suspects is not so hard to get working again. But he asked several times in the last years and no-one ever offered to help with MinGW, so it seems is a small niche of people [2]

Cquote1.png Linux/Unix users are generally more accustomed to building software from source - on Unix-based platforms it isn't rare even for non-developers to regularly configure/compile and install software - whereas it is much less common on Windows, which is why you need to install a bunch of things to even end up with a working build environment, whereas a Unix-based system will often have everything pre-installed. In addition, FlightGear is a complex piece of software, especially in terms of build-time/run-time dependencies - so people entirely new to the whole process of building software from source are likely to find this pretty frustrating. Personally, I also find setting up a build environment on Linux much easier than doing the same on Windows, despite being pretty familiar with the required workflows - but that doesn't have to do much with FG - the superbuild should help automate most of the required steps these days.

Then again, like I said previously, people struggling with even just building stock FG from source, will definitely not appreciate having to deal with git and other command line tools to build a customized FG versions, such as the osgEarth branch.

Cquote1.png most people on Windows are unlikely to even install a compiler/build environment at all.

And those few who do, can still make up their own minds about what tool chain to use.
Like you say, supporting mingw/mxe as an option would be a good thing for the code base, but it would also simplify providing pre-built binaries using a cross-compiler - i.e. we do have "power users" around here who are on *nix based systems who reguarly build custom fgfs binaries from source, but who cannot easily provide such binaries to Windows folks.
So supporting a mingw/mxe-based cross compiler would be a good thing, because not only could the *nix-based community more easily provide binaries for Windows folks. but also the build server could do this is an automated fashion, without necessarily requiring a VM with a full-blown MS windows environment just to run a compiler. Overall, I guess the first step really is understanding and extending the superbuild script to add osgEarth support to it - once that is the case, the changed superbuild script should receive much more testing, and get committed to fgmeta. But afterwards it would make sense to explore supporting either a cross-compiler or adding the superbuild-based osgEarth build to the build server.

Cquote1.png I agree completely, introducing cross-compiling support could be a good idea.

Testing & Development

1rightarrow.png See Howto:Cross platform development for the main article about this subject.

We may benefit from getting access to the Suse build service (or the gcc compile farm) for testing/running and developing the mxe specific parts.


should build & test shipped demos/examples (osgviewer) to ensure that integration works reliably


should build & test shipped demos/examples to ensure that integration works reliably


should build & test SimGear unit tests to ensure that integration works reliably


should build & test flightgear end-result(i.e make flight) and check whether we have any performance deficiencies.

Compiled binaries status

This is a list of binaries compiled and tested. (usually, but not always have dedicated *.mk modules for mxe)

Note  All main dependencies (osg,osgearth, simgear, flightgear) will by default be built using -DCMAKE_BUILD_TYPE=DEBUG to ensure that we can easily troubleshoot problems, once all unit tests (demos/examples) of each package build/link and work correctly, the build type for the corresponding package will be promoted to RelWithDbg.
Binary Status Description
fgjs working (build/link & run-time) "Joystick" on my laptop detected, but haven't checked the configuration process.
fgviewer working
Screenshot of running FGViewer under Wine
fgfs run-time error/segfault crash information
terragear run-time error/segfault still working on getting helpful backtrace, +sent msg to psadro_gm for questions on patches applied[5]

for starters, will be using utilities (/utils, e.g. fgviewer) and the minimal startup profile as detailed below:

Note  The following FlightGear startup profile assumes that you have a $FG_ROOT environment variable set up, or that you are explicitly setting fg-root using the --fg-root command line argument, this startup profile is intended to be put into your Fgfsrc file or to be used when starting FlightGear from the command line.

For FlightGear 2020.3 LTS and later versions: you can simply copy and paste the profile in Flightgear Qt launcher > Settings tab > Additional Settings .

This is a minimum startup profile. After using it, you can turn up settings one by one as performance allows - and observe your performance bottlenecks. See Hardware recommendations for discussion of performance bottlenecks.

The profile listed below is

  • name: minimal
  • version: 3.20
  • description: n/a
# --ignore-autosave # uncomment this for FlightGear versions >= 2.99
# --disable-textures

Development branches

Maintainer Feature Architichture Link type clone command binaries archive minidump/backtraces
Hamzaalloush Terragear i686-w64-mingw32 static
 git clone -b master-oldgcc-terragear
TODO:terragear binaries N/A
Hamzaalloush osgEarth i686-w64-mingw32 shared
 git clone -b master-oldgcc-osgearth
TODO:osgEarth binaries N/A

WinDbg (debugging using Windows SDK)

WineDbg (debugging under WINE)

GDB under Windows

If you're familiar with using GDB, you can compile GDB to be used in Windows through MXE. Just run

make gdb

for the same target as the target of the application you're planning on debugging (i.e. x86_64-w64-mingw32.shared gdb for x86_64-w64-mingw32.shared applications). To use GDB, you can try running it under Wine, but for me, the GDB prompt didn't work correctly. Whatever I typed into the GDB prompt (run, continue, etc.) resulted in nothing happening, and I had to end GDB by issuing a killall command in Linux. (Now that I think about it, it could be that GDB is looking for a Windows newline (\r\n), when only a Linux newline is being sent instead (\n).)

Instead I recommend you run GDB in an actual Windows machine. To do so, from Windows Explorer, you can Shift+Right Click and then select "Open new command prompt" (or some working to that effect). Then, you can run gdb.exe name-of-program.exe. All features of Linux GDB seem to work except for interrupting a program through Control-C.


What is MXE

MXE is essentially a set of useful tools and a Makefile, that provides a compact, command-line driven environment for which to cross-compile Windows binaries on Unix-like platforms.

MXE's Makefile

the Makefile provides a set of Unix portable target-rules for the native GNU make utility.

for the full set of targets that can be passed as arguments to the GNU make utility, visit:

for example, a simple:

$ cd mxe/
$ make

by use of native tools such as the GNU Make Standard Library functions and simple substitution, the Makefile parses through a list of package names, that are contained within an index.html file, and stores them into a white-space separated string.

MXE's Makefile, Line:47

PKGS       := $(call set_create,\
           $(shell $(SED) -n 's/^.* class="package">\([^<]*\)<.*$$/\1/p' '$(TOP_DIR)/index.html'))

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":

        <td class="package">simgear</td>
        <td class="website"><a href="">SimGear - Simulator Construction Tools</a></td>
        <td class="package">fgfs</td>
        <td class="website"><a href="">FlightGear Flight Simulator</a></td>

MXE's Makefile build process

MXE's Makefile, does not build software by itself. or rather, it does not generate configuration for software.

For example, if you were to pass the name of a package to be cross-compiled to the GNU make utility in MXE, such as:

$ make fgfs

a file in the src/ directory will be invoked that matches the name of the package followed by a suffix of ".mk", this ".mk" file does the necessary configuration and Makefile generation of software.

*.mk file template

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Note  This is a CMake-based template (e.g. for adding support for OpenSceneGraph, osgEarth, SimGear and FlightGear would look like this (with configuration options obviously being specific to the corresponding package) - for autotools, refer to [6] or any other autoconf based packages
# This file is part of MXE:
# This file specifies how to build: FOO
# See index.html for further information.

PKG             := foo
$(PKG)_IGNORE   :=
$(PKG)_VERSION  := 9000
# to compute the checksum use: openssl sha256 tarball.tar.gz
$(PKG)_CHECKSUM := 5c666531f7d487075fd692d89f1e05036306192a
$(PKG)_SUBDIR   := foo-$($(PKG)_VERSION)
$(PKG)_FILE     := foo-$($(PKG)_VERSION).tar.gz
$(PKG)_URL      :=$($(PKG)_FILE)
$(PKG)_DEPS     := gcc bar baz

define $(PKG)_UPDATE
    echo 'TODO: write update script for $(PKG).' >&2;
    echo $($(PKG)_VERSION)

define $(PKG)_BUILD
    mkdir '$(1).build'

    cd '$(1).build' && cmake '$(1)' \
        -DENABLE_BAR=ON \
        -DENABLE_BAZ=OFF \
# this is for static builds:
        $(if $(BUILD_STATIC), \
        -DSTATIC_FLAGS=1 , \

    $(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1

1rightarrow.png See [Creating mxe packages] for the main article about this subject.

Applying Patches

MXE patches are written in the git-format-patch style, there is a useful tool for automatic patch generation to this style:

cd mxe/
./tools/patch-tool-mxe init fgfs # this will download, extract and initialize package as a git repository into the mxe/gits directory.
cd gits/fgfs-version
# make changes here
git commit -a # commit your changes and descibe them
../tools/patch-tool-mxe export fgfs 1-patchname

this will automatically write your patches in git format, and move them to the /src directory, so they become src/fgfs-1-patchname, and are applied before compilation.

Further reading

Project inspiration

Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).

While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

Cquote1.png Your best would then be, mxe:

It's a massive compiler suite for cross-compiling Windows stuff on Linux - and comes with a ton of dependencies already.
On a multi-core server the whole build proceeds fairly quickly still.

And it should be possible to adapt the build script accordingly. But even the Superbuild should work without too much work.

Cquote1.png mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
Cquote1.png As of 10/2014, the mxe project also contains updated support for building OSG based applications using OSG 3.2.1 for 64 bit Windows, as per: ... 1486926850

(this even includes Qt5 support)

The cross-compiler used is

Detalis on setting up mxe are at:

Cquote1.png plib is already supported in master (see /src/

simgear would make sense - and once SG&FG work, we should also explore adding osgEarth as a supported dependency.
Once that is the case, the cmake superbuild should be easy to get working using mxe (including even osgEarth) - because all the deps should be there already.



For now, please see:

Regarding building in general, there is now a MXE_TMP variable that lets you configure where builds occur. This means that if you have sufficient RAM, then you may be able to use /dev/shm for the builds and get rid of the I/O overhead. Specifying this in MXE_TMP should be sufficient.

Regarding ccache, there isn't any ccache setup available in MXE. If this can be used without having to divert the actual compiler location or anything (just like "ccache x86_64-w64-mingw32.shared-gcc temp.c"), then this might be easy to do.

Before building mxe, you should consider installing ccache first, which also requires adapting the file in mxe:

sudo apt-get install ccache

Next, open src/ and add the ccache executable in front of the compiler executable (this will only affect mxe-conf.cmake, so it will only benefit cmake-based projects in its current form).

diff --git a/src/ b/src/
index 9a23619..c1e30e4 100644
--- a/src/
+++ b/src/
@@ -52,9 +52,9 @@ define $(PKG)_BUILD_COMMON
-     echo 'set(CMAKE_C_COMPILER $(PREFIX)/bin/$(TARGET)-gcc)'; \
-     echo 'set(CMAKE_CXX_COMPILER $(PREFIX)/bin/$(TARGET)-g++)'; \
-     echo 'set(CMAKE_Fortran_COMPILER $(PREFIX)/bin/$(TARGET)-gfortran)'; \
+     echo 'set(CMAKE_C_COMPILER ccache $(PREFIX)/bin/$(TARGET)-gcc)'; \
+     echo 'set(CMAKE_CXX_COMPILER ccache $(PREFIX)/bin/$(TARGET)-g++)'; \
+     echo 'set(CMAKE_Fortran_COMPILER ccache $(PREFIX)/bin/$(TARGET)-gfortran)'; \
      echo 'set(CMAKE_RC_COMPILER $(PREFIX)/bin/$(TARGET)-windres)'; \
      echo 'set(CMAKE_MODULE_PATH "$(PWD)/src/cmake" $${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts'; \
      echo 'set(CMAKE_INSTALL_PREFIX $(PREFIX)/$(TARGET) CACHE PATH "Installation Prefix")'; \

You should see pkgconf being rebuilt when running make again. Beginning with cmake 2.8, you can also directly add this at the top of mxe-conf.cmake:

diff --git a/src/ b/src/
index 9a23619..8de707b 100644
--- a/src/
+++ b/src/
@@ -44,6 +44,9 @@ define $(PKG)_BUILD_COMMON
     # individual packages (e.g. hdf5) should remove/append their own entries
     [ -d '$(dir $(CMAKE_TOOLCHAIN_FILE))' ] || mkdir -p '$(dir $(CMAKE_TOOLCHAIN_FILE))'
     (echo 'set(CMAKE_SYSTEM_NAME Windows)'; \
+     echo '#'; \
      echo 'set(MSYS 1)'; \
      echo 'set(BUILD_SHARED_LIBS $(if $(BUILD_SHARED),ON,OFF))'; \
      echo 'set(LIBTYPE $(if $(BUILD_SHARED),SHARED,STATIC))'; \

To see if you were successful adding ccache, check the generated toolchain file:

cat usr/x86_64-w64-mingw32.shared/share/cmake/mxe-conf.cmake

it should look like this:

set(MSYS 1)
set(CMAKE_FIND_ROOT_PATH /home/hooray/mxe/usr/x86_64-w64-mingw32.shared)
set(CMAKE_C_COMPILER ccache /home/hooray/mxe/usr/bin/x86_64-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER ccache /home/hooray/mxe/usr/bin/x86_64-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER ccache /home/hooray/mxe/usr/bin/x86_64-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hooray/mxe/usr/bin/x86_64-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hooray/mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hooray/mxe/usr/x86_64-w64-mingw32.shared CACHE PATH "Installation Prefix")
set(CMAKE_BUILD_TYPE Release CACHE STRING "Debug|Release|RelWithDebInfo|MinSizeRel")
set(CMAKE_CROSS_COMPILING ON) # Workaround for
set(CMAKE_RC_COMPILE_OBJECT "<CMAKE_RC_COMPILER> -O coff <FLAGS> <DEFINES> -o <OBJECT> <SOURCE>") # Workaround for buggy windres rules
set(PKG_CONFIG_EXECUTABLE /home/hooray/mxe/usr/bin/x86_64-w64-mingw32.shared-pkg-config)

to review ccache statistics, use (default cache is 1gb, so better raise this to ~3-5gb) :

$ ccache -s

Note  At least on Ubuntu, needs to be edited to add libgomp as a dependency for now
$ cd mxe
$ make openscenegraph  --jobs=2 JOBS=2

Dependencies should be resolved automatically, so that building osgearth should implicitly build osg first:

$ cd mxe
$ make osgearth  --jobs=2 JOBS=2


Wednesday, May 27, 2015 : OSG Shared library support done

Note  as of now, mxe-clone is able to cross-compile OSG 3.2.1 with shared library support on Ubuntu 14.04.2 distributions. so i'm raising the roadmap objective to 70% until i get the OSG examples and applications working. -- Hamzaalloush (talk) 16:06, 27 May 2015 (EDT)
$ find . -iname "*osg*"

Thursday, May 28, 2015 : OSG Applications/Examples built and tested working.

Note  examples and the osgviewer in action recorded, was using Wine at the time, but i tried it on Windows dual booted to same machine and it worked! -- Hamzaalloush (talk) 13:25, 28 May 2015 (EDT)

Wednesday, May 29, 2015 : Simgear Shared support done (Thanks to Flyhigh!)

Note  Building full (non-headless) Simgear now works. I've bumped up the progress to 50%, and once Flightgear is built, I'll set it to 100%. -- Flyhigh (talk) 14:16, 29 May 2015 (EDT)
$ find . -iname "*simgear*"

Sunday, May 31, 2015 : OSG-Earth built and examples tested.

optirun ./osgearth_version.exe --caps
osgEarth Library 2.6.0 ()

fixme:win:EnumDisplayDevicesW ((null),0,0x61f088,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x61f088,0x00000000), stub!
[osgEarth]  [Capabilities] Detected hardware capabilities:
[osgEarth]  [Capabilities]   Vendor = NVIDIA Corporation
[osgEarth]  [Capabilities]   Renderer = GeForce GT 540M/PCIe/SSE2
[osgEarth]  [Capabilities]   Version = 4.4.0 NVIDIA 331.113
[osgEarth]  [Capabilities]   Max FFP texture units = 4
[osgEarth]  [Capabilities]   Max GPU texture units = 32
[osgEarth]  [Capabilities]   Max GPU texture coord indices = 8
[osgEarth]  [Capabilities]   Max GPU attributes = 16
[osgEarth]  [Capabilities]   Depth buffer bits = 24
[osgEarth]  [Capabilities]   Max texture size = 16384
[osgEarth]  [Capabilities]   Max lights = 8
[osgEarth]  [Capabilities]   GLSL = yes
[osgEarth]  [Capabilities]   GLSL Version = 440
[osgEarth]  [Capabilities]   Texture arrays = yes
[osgEarth]  [Capabilities]   3D textures = yes
[osgEarth]  [Capabilities]   Multitexturing = yes
[osgEarth]  [Capabilities]   Stencil wrapping = yes
[osgEarth]  [Capabilities]   2-sided stencils = yes
[osgEarth]  [Capabilities]   depth-packed stencil = yes
[osgEarth]  [Capabilities]   occlusion query = yes
[osgEarth]  [Capabilities]   draw instanced = yes
[osgEarth]  [Capabilities]   max uniform block size = 65536
[osgEarth]  [Capabilities]   uniform buffer objects = yes
[osgEarth]  [Capabilities]   NPOT textures = yes
[osgEarth]  [Capabilities]   Compression = ARB S3 RG

Wednesday, June 9, 2015 : Shared FGViewer working

Note  I've uploaded the fgfs.log file, the command I ran, and the wine memory dump to a Github Gist. As for fgviewer, after including the path to the data directory, fgviewer works correctly. -- Flyhigh (talk) 11:38, 9 June 2015 (EDT)

Screenshot of running FGViewer under Wine


Note  This section contains sub-sections with open issues - which can be removed once they're solved/committed


  • For development purposes, it would make sense to focus on debug builds for now, and only begin supporting optimized builds when everything else is working correctly - or at least use RelWithDbg, as per Building_using_CMake#Debug_Builds.
  • For building OSG applications out-of-source-trees, it would make sense to introduce -DCMAKE_INSTALL_PREFIX, so that FindOpenSceneGraph.cmake can easily locate pre-installed OSG versions (as per our docs, and the existing cmake machinery in place in SG/FG), which also means that OSG would not need to be installed system-wide, while also supporting different versions at the same time.
  • We keep seeing people asking for ways to have an entirely self-contained FlightGear setup that doesn't require any installation (e.g. either all files residing in a single folder or the whole binary linked statically) - we used to support this a few years go, and we even had people using FG on a USB drive, or on boot-able drives - and we commonly suggest that people first try running FG on computers before purchasing any new hardware - so it would make sense to look at what's needed to still support static builds using the mxe tool chain. This may involve making the static/dynamic configuration options configurable in the corresponding *.mk files.


  • As request for custom scenery generation arises among end-users/data developers, we see the need for a cross-platform ready set of tools handy. since then the effort started for providing Terragear on Windows(initially by Hamzaalloush). It was expected that Terragear, as a scenery generation tool, that was made to deployed on a Linux server, would have portability problems. this effort would at least pinpoint issues with portability for the underlying structure of FlightGear.
  • The Terragear tools for scenery generation would be the ideal environment on which to bring "Small, stable, incremental changes which are preferable to larger monolithic changes for ease of review", adhering to the FG roadmap for development, since we are mainly dealing with the basic building blocks for Flightgear, where a Simgear based environment is the only prerequisite. the SG abstraction layer for threading, as well as for maths are good points to investigate in this setup(as it is used throughly), as well as providing small patches upstream towards getting Simgear, Mingw64 compatible as the end-goal.
  • The relatively smaller number of static symbols collected from such an effort, is a good basis for investigating debugging facilities on cross-compiled binaries.