Building FlightGear - Cross Compiling
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 4.x. If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear. |
This article is a stub. You can help the wiki by expanding it. |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
Started in | 05/2015 |
---|---|
Description | Windows binaries created using a cross compiler on Linux |
Maintainer(s) | hamzaalloush and hooray |
Contributor(s) | hamzaalloush (since 05/2015) |
Status | Under active development as of 05/2015 |
Changelog | https://github.com/hamzaalloush/mxe-clone |
Background
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. — Hooray (Mon Apr 06). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
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. — Hooray (Thu Apr 09). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
I agree completely, introducing cross-compiling support could be a good idea.
— elgaton (Thu Apr 09). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
Idea
do we really need Windows SDK's? can't we find a similar toolchain like Mingw using GCC for example? i think VS support non-native compilers as well? we can then skip this whole thing and probebly even adopt a modified version of the debian build script
— hamzaalloush (Wed Apr 08). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
I also think is better using free software tools to compile it and incidentally make it easier
— Catalanoic (Wed Apr 08). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
Testing & Development
See Howto:Cross platform development for the main article about this subject. |
We may benefit from getting access to the Suse build service for testing/running and developing the mxe specific parts.
MXE
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 a full set of target-rules that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage
for example, a simple:
$ cd mxe/ $ make
this will parse through, a table set of software names, that are contained within an index.html file.
it does by way of use the GNU Make Standard Library, using set_create, an example of this is. mxe/Makefile, Line:47, exporting the variable ${PKGS} with all software names found in index.html:
PKGS := $(call set_create,\ $(shell $(SED) -n 's/^.* class="package">\([^<]*\)<.*$$/\1/p' '$(TOP_DIR)/index.html'))
an example of a software name, which is contained in this table set of software names, is:
<tr> <td class="package">fgfs</td> <td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator: free open-source multiplatform flight sim</a></td> </tr>
MXE's Makefile build process
MXE's Makefile, does not build software by itself. or rather, it does not generate configuration for software, it instead acquires software name from the table set of software names, it then passes this string returned by <td class="package">fgfs</td> to a variable $(1), it export $(1)="" in this example to $(1)="fgfs".
for example, if you were to pass the name of the software to be cross-compile to the GNU make utility, such as:
$ make fgfs
$(1) would be substituted by "fgfs".
in the mxe/Makefile, Line:362, 'make' will only build a blank file such as $(PREFIX)/$(3)/installed/$(1), which attempts to declare a successful build when all the commands below returned an exit status of (0), example.
.PHONY: $(1) $(1): $(PREFIX)/$(3)/installed/$(1) $(PREFIX)/$(3)/installed/$(1): $(TOP_DIR)/src/$(1).mk \ $(wildcard $(TOP_DIR)/src/$(1)-*.patch) \ $(wildcard $(TOP_DIR)/src/$(1)-test*) \ $(addprefix $(PREFIX)/$(3)/installed/,$(value $(call LOOKUP_PKG_RULE,$(1),DEPS,$(3)))) \ | $(if $(DONT_CHECK_REQUIREMENTS),,check-requirements) $(3)
an installed/$(1) file, is a file indicating what MXE thought was a successful build, so a $(PREFIX)/$(3)/installed/fgfs, is an empty file generated for this purpose. $(PREFIX): returns the absolute path of ${mxe_dir}/usr $(3): is the triplet name, in the form of ${triplet}.${linker_configuration}. see: https://sourceforge.net/p/mingw-w64/wiki2/TypeTriplets/
to obtain a cross-compilation of a useful software, MXE refers to a file in the ${mxe_dir}/src/ directory that contains a file with string $(1), suffixed by ".mk" (example, fgfs.mk), this file is used for configuration and Makefile generation of software.
*.MK file
'TO DO'
Project inspiration
Your best would then be, mxe: http://mxe.cc/ It's a massive compiler suite for cross-compiling Windows stuff on Linux - and comes with a ton of dependencies already. — Hooray (Wed Apr 08). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
— Hooray (Fri Apr 17). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
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: https://github.com/mxe/mxe/commit/c7deb ... 1486926850
— Hooray (Wed Apr 08). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
plib is already supported in master (see /src/plib.mk)
— Hooray (Sat Apr 18). Re: Help me! Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
Status
MXE is such a joy to work with, the folks on the mailing list are helpful in providing patches to get a fellow's toolchain working, but currently they also have some limitations, because they cannot directly maintain errors produced by the upstream mingw back-end compiler. i have carried a successful build of their static toolchain with some local patches that i applied.
— hamzaalloush (Thu May 14). Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
mingw has came a long way, and i think the MXE openscenegraph package (currently at 3.2.1 on master!!), is beautifully maintained, now it builds almost all core libraries dynamically with some argument passing, even as a static target(MXE_TARGETS='i686-w64-mingw32.static'), but it's those plugins again, with their linking errors! i think these are because i'm using the i686-w64-mingw32.static-g++ compiler as opposed to the shared one...
— hamzaalloush (Thu May 14). Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
so as soon as i can get the shared build environment running and solve all of it's dependancies for OSG, i think we can have a cross compiller in our hands! :)
— hamzaalloush (Thu May 14). Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi.
(powered by Instant-Cquotes) |
Issues
OpenSceneGraph
Roadmap
Task | Description | Progress |
---|---|---|
plib | provide mxe build scripts for plib | Done |
openrti | add OpenRTI support | |
optional | add support for optional dependencies | Not done |
simgear | provide mxe build scripts for simgear | Not done |
osg support | improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) ensure that all OSG examples build/link properly via -DBUILD_OSG_EXAMPLES=ON and -DBUILD_OSG_APPLICATIONS=ON | |
flightgear | provide mxe build scripts for flightgear | Not done |
Superbuild | Update the CMake Superbuild to support mxe | Not done |
osg-earth | update the Superbuild to support osgEarth | Not done |
packages | provide binary mxe packages (deb/ppa) | Not done |
VM | provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up | Not done |
build server | get the FlightGear Build Server updated to support mxe-based cross-builds | Not done |
3rdParty | ensure 3rd party dependancies are built in the toolchain, and merge their *.mk packages in the clone | |
mxe 32-bit static tool-chain | progress of the static mxe i686-w64-mingw32-based tool-chain | Done |
mxe 32-bit shared tool-chain | progress of the shared mxe i686-w64-mingw32-based tool-chain | |
flightgear specific mxe tool-chain | provide minimal set of packages neccessary for the flightgear project, rather than the full 367 packages |
|