FlightGear wiki - User contributions [en]

Howto:Install Flightgear from a PPA

2017-09-09T21:47:37Z

Flyhigh:

Currently, in the official Ubuntu repositories, Ubuntu 14.04 (Trusty) has FlightGear 3.0.0, Ubuntu 16.04 (Xenial) has FlightGear 3.4.0, and Ubuntu 17.04 (Zesty) has FlightGear 2016.4.4. Since the older Ubuntu versions don't have a simple installation method for the latest FlightGear version, I'm providing a PPA from which you can download FlightGear. Here is a list of FlightGear-related PPAs:

* Stable: [https://launchpad.net/~saiarcot895/+archive/flightgear FlightGear]
* Daily(ish): [https://launchpad.net/~saiarcot895/+archive/flightgear-edge FlightGear Daily]

== Installing FlightGear ==
{{note|The menu bar may be initially hidden. You can restore this by pressing {{Key press|F10}}.}}

{{caution|You '''must''' be on Ubuntu 14.04, 16.04, or 17.04 (packages for 17.10 coming shortly) before you install FlightGear!<ref>
{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=20&t=28893#p277811
|title = Problem installing Flightgear
|author = saiarcot895
|date = Feb 27th, 2016
}}</ref>

If you aren't on one of those three versions of Ubuntu, you can upgrade by executing the following command in the terminal:
<syntaxhighlight lang="bash">
sudo do-release-upgrade
</syntaxhighlight>
Note that the upgrade may take several hours.}}

=== Upgrading ===
If you already have Flightgear installed from the main repos, you can just add the PPA, update, and upgrade.
<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get dist-upgrade
</syntaxhighlight>

=== Fresh install ===

If you are doing a fresh FlightGear install (you haven't installed FlightGear from this PPA or the prerelease/daily PPAs) and you haven't added this PPA, you'll need to do the commands below:
<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get install flightgear
</syntaxhighlight>

== Installing additional aircraft (daily PPA only) ==
I've since removed the aircraft packages, since there is now an integrated launcher that lets you download any aircraft you want.

{{Appendix}}

[[Category:Howto|Install Flightgear from a PPA]]

Howto:Install Flightgear from a PPA

2016-02-27T19:25:43Z

Flyhigh: Update for 2016.1.1

Currently, in the official Ubuntu repositories, Ubuntu 14.04 (Trusty) has FlightGear 3.0.0, and Ubuntu 15.10 (Wily) has FlightGear 3.4.0. Since the older Ubuntu versions don't have a simple installation method, I'm providing a PPA from which you can download FlightGear and some aircraft from. Here is a list of FlightGear-related PPAs:

* Stable: [https://launchpad.net/~saiarcot895/+archive/flightgear FlightGear]
* Prerelease: [https://launchpad.net/~saiarcot895/+archive/flightgear-prerel FlightGear Prerelease] (only active when there is a new release coming up)
* Daily(ish): [https://launchpad.net/~saiarcot895/+archive/flightgear-edge FlightGear Daily]

== Installing FlightGear ==
{{note|The menu bar may be initially hidden. You can restore this by pressing {{Key press|F10}}.}}

{{caution|You '''must''' be on Ubuntu 14.04, 15.10, or 16.04 before you install FlightGear! Ubuntu 12.04 is no longer supported.<ref>
{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=20&t=28893#p277811
|title = Problem installing Flightgear
|author = saiarcot895
|date = Feb 27th, 2016
}}</ref>

If you aren't on one of those three versions of Ubuntu, you can upgrade by executing the following command in the terminal:
<syntaxhighlight lang="bash">
sudo do-release-upgrade
</syntaxhighlight>
Note that the upgrade may take several hours.}}

=== Upgrading ===
If you already have Flightgear installed from the main repos, you can just add the PPA, update, and upgrade.
<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get dist-upgrade
</syntaxhighlight>

=== Fresh install ===

If you are doing a fresh FlightGear install (you haven't installed FlightGear from this PPA or the prerelease/daily PPAs) and you haven't added this PPA, you'll need to do the commands below:
<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get install flightgear
</syntaxhighlight>

== Installing additional aircraft (daily PPA only) ==
I am providing some additional aircraft that you can download straight from the PPA. To install them, run the following command:
<syntaxhighlight lang="bash">
sudo apt-get install flightgear-data-aircrafts-<aircraftname>
</syntaxhighlight>

Replace <nowiki><aircraftname></nowiki> with one of the following:

{| class="wikitable"
! <nowiki><aircraftname></nowiki> !! Aircraft
|-
| a10 || [[Fairchild Republic A-10 Thunderbolt II]]
|-
| a380 || [[Airbus A380]]
|-
| b747-400 || [[Boeing 747-400]]
|-
| b707 || [[Boeing 707-420]]
|-
| dc3 || [[Douglas DC-3]]
|-
| dr400-dauphin || [[Robin DR400 Dauphin]]
|-
| ec130 || [[Eurocopter EC130 B4]]
|-
| p51d || [[North American P-51 Mustang]]
|-
| seafire || [[Supermarine Seafire]]
|-
| spitfire || [[Supermarine Spitfire]]
|-
| tu154b || [[Tupolev Tu-154B]]
|}

{{Appendix}}

[[Category:Howto|Install Flightgear from a PPA]]

Howto:Install Flightgear from a PPA

2015-10-25T18:36:35Z

Flyhigh: Update list of FG versions in the repo, and correct intention of post

Currently, in the official Ubuntu repositories, Ubuntu 12.04 (Precise) has [[FlightGear]] 2.4.0, Ubuntu 14.04 (Trusty) has FlightGear 3.0.0, and Ubuntu 15.04 (Vivid) and Ubuntu 15.10 (Wily) have FlightGear 3.4.0. Since the older Ubuntu versions don't have a simple installation method, I'm providing a PPA from which you can download FlightGear and some aircraft from. Here is a list of FlightGear-related PPAs:

* Stable: [https://launchpad.net/~saiarcot895/+archive/flightgear FlightGear]
* Prerelease: [https://launchpad.net/~saiarcot895/+archive/flightgear-prerel FlightGear Prerelease] (only active when there is a new release coming up)
* Daily(ish): [https://launchpad.net/~saiarcot895/+archive/flightgear-edge FlightGear Daily]

== Installing FlightGear ==
{{note|The menu bar may be initially hidden. You can restore this by pressing {{Key press|F10}}.}}

=== Upgrading ===
You can just update and upgrade. Note that, after the upgrade, you will have the packages libsimgearcore2.12.0 and libsimgearscene2.12.0. You can safely remove these two libraries after the upgrade.
<syntaxhighlight lang="bash">
sudo apt-get update
sudo apt-get dist-upgrade
</syntaxhighlight>

=== Fresh install ===
{{caution|You '''must''' be on a supported version of Ubuntu before you install FlightGear! Currently, this is 12.04, 14.04, 15.04, and 15.10.<ref>
{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=20&t=27804#p261635
|title = Can't install FlightGear-daily on my Ubuntu 14.10
|author = saiarcot895
|date = Oct 25th, 2015
}}</ref>

If you aren't on a supported version of Ubuntu, you can upgrade by executing the following command in the terminal:
<syntaxhighlight lang="bash">
sudo do-release-upgrade
</syntaxhighlight>
Note that the upgrade may take several hours.}}

If you are doing a fresh FlightGear install (you haven't installed FlightGear from this PPA or the prerelease/daily PPAs) and you haven't added this PPA, you'll need to do the commands below:
<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get install flightgear
</syntaxhighlight>

== Installing additional aircraft ==
I am providing some additional aircraft that you can download straight from the PPA. To install them, run the following command:
<syntaxhighlight lang="bash">
sudo apt-get install flightgear-data-aircrafts-<aircraftname>
</syntaxhighlight>

Replace <nowiki><aircraftname></nowiki> with one of the following:

{| class="wikitable"
! <nowiki><aircraftname></nowiki> !! Aircraft
|-
| a10 || [[Fairchild Republic A-10 Thunderbolt II]]
|-
| a380 || [[Airbus A380]]
|-
| b747-400 || [[Boeing 747-400]]
|-
| b707 || [[Boeing 707-420]]
|-
| dc3 || [[Douglas DC-3]]
|-
| dr400-dauphin || [[Robin DR400 Dauphin]]
|-
| ec130 || [[Eurocopter EC130 B4]]
|-
| p51d || [[North American P-51 Mustang]]
|-
| seafire || [[Supermarine Seafire]]
|-
| spitfire || [[Supermarine Spitfire]]
|-
| tu154b || [[Tupolev Tu-154B]]
|}

{{Appendix}}

[[Category:Howto|Install Flightgear from a PPA]]

Talk:Building FlightGear - Cross Compiling

2015-06-24T15:05:49Z

Flyhigh: /* Simgear Test Crashes */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

: If we reach the stage where we succeed building/linking everything, but keep getting segfaults, we should definitely investigate prioritizing debugging support (e.g. using breakpad or some other mechanism that works sufficiently well (winedbg?)). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:25, 11 June 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== fgfs backtraces ==

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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

: is that also happening with the minimal startup profile being used ? and what about explicitly disabling scenery altogether ? If in doubt, please use the minimal startup profile and post your fgfs.log file so that we can take a look. It may be worthwhile to add a few SG_LOG() statements to the startup sequence in $FG_SRC/Main/fg_init.cxx to see what is going on - if that still isn't conclusive, I'd suggest to link in a debugging library like Breakpad which should be helpful to come up with a meaningful backtrace. Regarding fgviewer, what about the osgviewer/osgearthviewer binaries, do they work as expected ? I'd suggest that we add a table to the main article with all programs that are known to work/not work, so that we can more easily troubleshoot things in the time to come..
: {{unsigned|10:02, 8 June 2015‎|Hooray}}

:: 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)

::: I would suggest running this inside gdb to get an annotated backtrace with source code shown - alternatively, we need to prioritize adding support for BreakPad, which should help with this. Also, is this using the minimal startup profile or just the default settings at ksfo ? If in doubt, I would also check that all sg/fg unit tests are working correctly, to see if that brings up any suspects. But for troubleshooting purposes, I would definitely first try the minimal startup profile as per the article (no multiplayer, scenery, terrasync etc)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:14, 9 June 2015 (EDT)

:::: I'v just read that link you posted about BreakPad, i like the idea of using a crash collecter to store the internal symbols of objects during compilation, so that it can be referenced against a mini-dump. it also support symbols generated in "OS X/Linux, DWARF" format, which is optimal for GCC. should we start to have a central server for crash collection? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:41, 11 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

: get into the CMake lists for that object that's failing to link, "present3D.exe". and define the missing libraries in "link_to_target". you would have to search google from which API these calling functions came from. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:11, 8 June 2015 (EDT)

:: I did that for one round, but that yielded another set of undefined references, as those libraries called other libraries. Is there any way to compile it other than completely specifying all dependencies? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:13, 8 June 2015 (EDT)

::: you could try to remove that target that's pulling tons of dependencies. if non of the other targets links with, maybe try to delete/edit its CMakeLists? alternatively you can disable these dependencies from the library. if these are GDAL related dependancies, then you can try to use a helper executable, like 'gdal-config.exe --dep-libs' and append these results into a variable, which is what i did for Terragear. https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc-terragear/src/cmake/FindGDAL.cmake (Line 27, find dependencies. Line 52, append to variable) -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:14, 8 June 2015 (EDT)

== excessive qoutes, user talk style ==
i suggest removing some of the qouting, i'd offer remove my qouting if no one minds, as i look to make our page cleaner, also what about some cleaner talk/reply style, any ideas? as excessive threading makes the talk unreadable in some instances -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:12, 8 June 2015 (EDT)

: sure, feel free to consider this "your" article and just go ahead - quotes are usually just intended to help "bootstrapping" new articles/projects, and should be phased out over time, unless some decisions/priorities need to be backed up by links to the corresponding statements - right now, the article has seen 1.8k views and dozens of edits, and it seems pretty safe to say that the article will stay around even if this effort should get stalled at some point, so unlike many other articles, this is already useful and documents and actual project.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 04:56, 9 June 2015 (EDT)

== repository relevant talk ==

a section, that contains a list will be created that you'll have to fill up to reflect what your working on. elements in the list are: owner, what it does/what feature it is supposed to create, which architichture, linking type, clone command + url. also, i suggest we rebase each feature from master-oldgcc for now(until we get a working GCC 5). -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:58, 11 June 2015 (EDT)

== Simgear Test Crashes ==

I've been under the assumption that the tests in Simgear are run automatically with every build. I didn't realize that thy had to be run manually (side-effect of using dh in Debian packaging, which does everything automatically for you). After running the tests, two tests crash, two tests go up to 100% CPU for at least a minute (before I killed those tests), one seemed to hang after completing successfully, and one seemed to have been called incorrectly (it was missing an argument). Below are the results:

* test-simgear_canvas_layout-canvas_layout.exe - Crash
* sg_pkgutil.exe - Crash, infinite recursion in what seems to be the Wine loader
* test_sock.exe - Hang after completion
* http_get.exe - 100% CPU
* http_svn.exe - 100% CPU
* decode_binobj.exe - Incorrect usage? Called with no arguments, when one argument was expected?

This was on x86_64-w64-mingw32.shared. I'll be compiling GDB soon, and hopefully, I can get a backtrace. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 15:40, 13 June 2015 (EDT)

: [https://gist.github.com/saiarcot895/8c032c0ebbc13da0e26f Here's] the stacktrace for test-simgear_canvas_layout-canvas_layout crashing. Don't know how useful it is... -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:28, 16 June 2015 (EDT)

:: Not sure if this will help, but i notice your using the "release" runtime of boost rather than debug, so if you want to make sure, you can try rebuild boost with "./b2 ... variant=debug ...", atleast it will be helpful to look at the boost code as well. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:37, 17 June 2015 (EDT)

::: Those functions are Boost unit testing framework which should just be calling the Simgear tests, so I don't think having a debug version of that library will help much. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:43, 19 June 2015 (EDT)

:::: can you tell us what steps can we take to compile Simgear and replicate these tests?(which branch, debugging methods etc, helpful if you wrote a section for debugging in the article). also, i was more concerned with the symbols included in the boost library rather than just the functions, for debugging reason. because i recieved info from Hooray that it is a suspected boost fault. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:40, 19 June 2015 (EDT)

Regarding the building, it should be the current version of my master-oldgcc branch (c139f66) and building simgear and gdb for the x86_64-w64-mingw32.shared target. Note that the tests are not run, since it seems CMake decides to directly mark them as failed. For the testing itself, I copied all of the DLL files in usr/x86_64-w64-mingw32.shared/bin/, the gdb binary, and the test executables from the build (make sure you get these files before the build completes, as once the build completes, the build directory is removed; if it's too quick, you can induce a build failure by uncommenting the tests line, while will save the build directory) into Windows and ran gdb from there. (Note that you may need to copy libdl.dll to libdl.dll.a if you can't launch gdb) The reason I didn't run it from Wine in Linux is because the gdb prompt didn't seem to work correctly in Wine. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:34, 19 June 2015 (EDT)

: It's definitely something in Simgear's ghost (or in calling ghost). I've built a 64-bit shared version of Flightgear, and it crashes when calling nasal::internal::GhostMetadata::addDerived. GDB backtrace is [https://gist.github.com/saiarcot895/0d795876ad3913023514 here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:05, 24 June 2015 (EDT)

== Breakpad.mk ==

'''1.''' I'v been working towards getting Breakpad cross-compiled through MXE, and so far i'v been able to build using simple Mingw-specific portability fixes: [http://pastebin.com/xmb9f4FX]

i'm still having issues compiling the basic example provided in the [https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide LinuxStarterGuide]

The breakpad.mk is a simple one, adopting autotools, using the $(MXE_CONFIGURE_OPTS) placeholder, and linking the ws2_32 runtime for <winsocks.h> support. right now, i have not found a mirror providing a recent Breakpad archive, so i tarred the source straight from a cloned repository, and are experimenting using a local server, feel free to modify the .mk file accordingly. [http://pastebin.com/LFq8yfmn breakpad_WIP.mk]

the issues that i'm having consists of configure tests not running properly(suspected configure output variables: '''ANDROID_HOST_TRUE='#''''), and therefore are applying headers that are android specific, and are expecting android specific runtime's. resulting in this error from missing Android SDK [https://code.google.com/p/google-breakpad/issues/detail?id=625 Issue 625: compile failed on android].

A configure patch is due, here's the full log of [http://pastebin.com/Zkp2MiVD configure tests]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:38, 22 June 2015 (EDT)

'''2.''' looks like the [https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide LinuxStarterGuide] provided example, requires include of the vanilla source as well as linking with the built library ''libbreakpad_client.a''("First, configure your build process to link libbreakpad_client.a into your binary, and set your include paths to include the src directory in the google-breakpad source tree."), but the source unfortunately requests the Android SDK through headers such as elf.h/link.h/ucontext.h. therefore for all intents and purposes, the binaries built from Breakpad's cross-compilation are working, although not tested with real application, i could get an output on the terminal when invoking them, what's left is integration and some form of testing which i am unable to do. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:04, 22 June 2015 (EDT)

Building FlightGear - Cross Compiling

2015-06-20T03:46:02Z

Flyhigh: /* Testing & Development */

{{Non-stable|version=4.x|progress=30}}
{{-}}
{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|image = Fg-via-mxe-logo.png
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|70}} (compiles & runs OSG/osgEarth examples)
|maintainers = {{usr|Hamzaalloush}} and {{usr|Hooray}}
|developers = hamzaalloush, FlyHigh (since 05/2015)
|changelog =  https://github.com/saiarcot895/mxe/commits/master-oldgcc
}}

== News ==
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. [https://gist.github.com/saiarcot895/389c699af30a91d2774b 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".
-- [[User:Flyhigh|Flyhigh]] ([[User talk: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.

== Gallery ==
<gallery mode=packed widths=230px heights=230px>
OSG Earth.png|showing the symbolic osg earth :)
OSGEarth Boston Baseball.png|example what OSM buildings look like with OSG-Earth textures
</gallery>

== Roadmap ==
{{Note|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 simgear.mk for reference).}}

{| class="wikitable"
! Task !! Description !! Priority || People !! Progress
|-
| mxe 32-bit '''static''' tool-chain || progress of the '''static''' mxe i686-w64-mingw32-based tool-chain || [[File:Stars-1.png]] || {{Usr|Hamzaalloush}}|| {{Done}}
|-
| mxe 32-bit '''shared''' tool-chain || progress of the '''shared''' mxe i686-w64-mingw32-based tool-chain ||[[File:Stars-5.png]]|| {{Usr|Hamzaalloush}} & {{Usr|FlyHigh}}|| {{Progressbar|50}}
|-
| mxe 64-bit '''static''' tool-chain || progress of the '''static''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| mxe 64-bit '''shared''' tool-chain || progress of the '''shared''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| flightgear specific mxe tool-chain || mxe subset/progress of packages neccessary for the flightgear project, rather than the full 367 packages ||[[File:Stars-1.png]]||Hamzaalloush|| {{Progressbar|70}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] ||[[File:Stars-5.png]] || || {{Not done}}
|-
| leak checking support || add support for leak checking using [https://code.google.com/p/address-sanitizer/ Address Sanitizer] via <nowiki>-fsanitize=address -fno-omit-frame-pointer</nowiki> [https://github.com/sanhozay/fgbuild/blob/master/fgbuild#L82] ||[[File:Stars-3.png]]||...|| {{Not done}}

|-
| packages || provide binary mxe packages (deb/ppa) - e.g. via cmake/cpack [http://www.cmake.org/Wiki/CMake:CPackPackageGenerators] ||[[File:Stars-2.png]]||FlyHigh (?)|| {{Not done}}
|-
| VM || provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up ||[[File:Stars-2.png]]||Hooray|| {{Not done}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe ?? ||[[File:Stars-0.png]] || Hooray||{{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|Superbuild to support osgEarth]] ||priority || people|| {{Not done}}
|-
| build server || get the [[FlightGear Build Server]] updated to support mxe-based cross-builds ||mid-term||Jenkins maintainers|| {{Not done}}
|-
| Simgear portability || ensure Simgear is portable ''upstream'' for different platforms. (ex. Mingw64 is a different platform) ||[[File:Stars-5.png]]|| core developers|| {{Not done}}
|}

=== Dependencies ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Task !! Build System !! Description !! People !! Progress
|-
| plib.mk || autotools || provide mxe build scripts for plib || || {{Done}}
|-
| openrti.mk || cmake || add OpenRTI support ||Hamzaalloush|| {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] (probably, separate *.mk files for each) || || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone |||| {{Progressbar|80}}
|-
| simgear.mk ||cmake|| provide mxe build scripts for simgear || {{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| openscenegraph.mk support (shared library) ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Usr|Hamzaalloush}} & {{Usr|FlyHigh}}|| {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || || {{Progressbar|90}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth.mk]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) also see gdal issue discussed at [http://comments.gmane.org/gmane.comp.gnu.mingw.cross-env/3607] ||Hamzaalloush|| {{Progressbar|70}}
|-
| flightgear.mk ||cmake|| provide mxe build script for flightgear ||{{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| breakpad.mk ||cmake|| provide mxe build script for [https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad breakpad] Windows integration instructions at [https://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration] || Hooray || {{Not done}}
|-
| sigar.mk ||cmake|| provide mxe build script for [https://github.com/hyperic/sigar sigar -System Information Gatherer And Reporter] (cmake based, for better startup/run-time diagnostics on CPU/RAM utilization) || Hooray || {{Not done}}
|-
| Makefile SVN support || 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|| {{Progressbar|20}}
|-
| terragear.mk || cmake || build static monolithic TerraGear (compiles but segfaults) ||Hamzaalloush|| {{Progressbar|40}}
|}

== Goals ==
{{forum|81|FlightGear/osgEarth}}

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 [[Built-in Profiler|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:

{{FGCquote
|Is there somewhere an option to get a stacktrace when FG crashes?
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177395#p177395
|title=<nowiki>Re: FG Crash reported to Microsoft.</nowiki>
|author=<nowiki>Necolatis</nowiki>
|date=<nowiki>Sat Feb 16</nowiki>
}}
}}

{{FGCquote
| 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]]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177508#p177508
|title=<nowiki>Re: FG Crash reported to Microsoft. </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Feb 18</nowiki>
}}
}}

{{FGCquote
|BreakPad would be useful in getting higher quality crash reports
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192032#p192032
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
|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: [http://www.flightgear.org/forums/viewtopic.php?f{{=}}68&t{{=}}18942#p176669 http://www.flightgear.org/forums/viewto ... 42#p176669]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177561#p177561
|title=<nowiki>Re: Release 2.10 - not fixed bugs</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 19</nowiki>
}}
}}

{{FGCquote
|If we could teach the build server to build fgfs binaries with [http://code.google.com/p/google-breakpad/ 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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192031#p192031
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
| 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): [http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad http://code.google.com/p/google-breakpa ... thBreakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=176669#p176669
|title=<nowiki>Re: [Windows] FlightGear 2.10.0.0 RC1</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Feb 08</nowiki>
}}
}}

{{FGCquote
|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.
* [https://wiki.mozilla.org/Breakpad https://wiki.mozilla.org/Breakpad]
* [http://code.google.com/p/google-breakpad/ http://code.google.com/p/google-breakpad/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15078#p15078
|title=<nowiki> open source crash reporter</nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Mon Aug 11</nowiki>
}}
}}

{{FGCquote
|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/ [http://kb.mozillazine.org/Breakpad http://kb.mozillazine.org/Breakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15347#p15347
|title=<nowiki>Re: </nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Sat Aug 16</nowiki>
}}
}}

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) for testing/running and developing the mxe specific parts.

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

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

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

=== FlightGear ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Binary !! Status !! Description
|-
| fgjs || '''working''' (build/link & run-time) || "Joystick" on my laptop detected, but haven't checked the configuration process.
|-
| fgviewer || '''working''' || [[File:Fgviewer under wine.png|thumb|Screenshot of running FGViewer under Wine]]
|-
| fgfs || '''run-time error/segfault''' || [https://gist.github.com/saiarcot895/389c699af30a91d2774b crash information]
|-
| terragear || '''run-time error/segfault''' || still working on getting helpful backtrace, +sent msg to psadro_gm for questions on patches applied[https://github.com/hamzaalloush/mxe-clone/blob/b76befe28c42c4491a786bdc357a9ce3f02f47ad/src/terragear-1-mxe.patch]

|}

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

{{Startup Profile}}

=== Development branches ===

{| class="wikitable"
! Owner !! Feature !! Architichture !! Link type !! clone command !! binaries archive !! minidump/backtraces
|-
| {{usr|Hamzaalloush || Terragear || i686-w64-mingw32 || static || <syntaxhighlight lang="bash"> git clone -b master-oldgcc-terragear https://github.com/hamzaalloush/mxe-clone.git </syntaxhighlight> || TODO:terragear binaries || N/A
|-
| {{usr|Hamzaalloush || osgEarth || i686-w64-mingw32 || shared || <syntaxhighlight lang="bash"> git clone -b master-oldgcc-osgearth https://github.com/hamzaalloush/mxe-clone.git </syntaxhighlight> || TODO:osgEarth binaries || N/A

|}

=== WinDbg (debugging using Windows SDK) ===

* [http://blog.morlad.at/blah/mingw_postmortem Generating PDB Symbols] (cv2pdb to convert the DWARF debug info into PDB format, for use by Windows SDK)

=== WineDbg (debugging under WINE)===

* [http://wine-wiki.org/index.php/Winedbg Winedbg]
* [https://www.winehq.org/docs/winedev-guide/dbg-others Wine GDB mode]
* [http://mingw-cross.sourceforge.net/cross_debug.html Cross Debug on Linux and Wine]
* [http://ftp.winehq.org/pub/wine/docs/en/winedev-guide.html Wine Developer's Guide]

=== GDB under Windows ===

If you're familiar with using GDB, you can compile GDB to be used in Windows through MXE. Just run <syntaxhighlight lang="bash">make gdb</syntaxhighlight> 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 (<nowiki>run</nowiki>, <nowiki>continue</nowiki>, etc.) resulted in nothing happening, and I had to end GDB by issuing a <nowiki>killall</nowiki> 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 <nowiki>gdb.exe name-of-program.exe</nowiki>. All features of Linux GDB seem to work except for interrupting a program through Control-C.

== 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

{{Note|This is a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package) - for autotools, refer to [https://github.com/saiarcot895/mxe/commit/e028a0a9f53c64266108177848eed90aea1958dd] or any other autoconf based packages}}

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

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

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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 ===
* [https://code.google.com/p/mupen64plus/wiki/CrossCompilingOnLinux Compiling Mupen64Plus from source code under Linux for Windows]
* [http://ejdb.org/doc/install/building.html Building native Windows libs on Linux]
* [https://www.93i.de/devzone/mxe-and-dynamic-linking mxe and dynamic linking using the MXE_TARGETS environment variable]
* [http://www.cs.cmu.edu/~soonhok/mxe-cross-compile-windows-binaries-on-ubuntu.html MXE: cross-compile windows binaries on ubuntu]

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

== Contributing ==
For now, please see:
* Requirements: http://mxe.cc/#requirements
* Getting started: http://mxe.cc/#tutorial
* Getting mxe: http://mxe.cc/#download
* Building mxe: http://mxe.cc/#usage
* Creating packages: http://mxe.cc/#creating-packages

Before building mxe, you should consider installing ccache first, which also requires adapting the pkgconf.mk file in mxe:
<syntaxhighlight lang="bash">
sudo apt-get install ccache
</syntaxhighlight>

Next, open src/pkgconf.mk 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).
<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..c1e30e4 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -52,9 +52,9 @@ define $(PKG)_BUILD_COMMON
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)'; \
- 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")'; \
</syntaxhighlight>

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:
<syntaxhighlight lang="cmake">
# http://stackoverflow.com/a/24305849
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
</syntaxhighlight>

<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..8de707b 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -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 '# http://stackoverflow.com/a/24305849'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)'; \
echo 'set(MSYS 1)'; \
echo 'set(BUILD_SHARED_LIBS $(if $(BUILD_SHARED),ON,OFF))'; \
echo 'set(LIBTYPE $(if $(BUILD_SHARED),SHARED,STATIC))'; \

</syntaxhighlight>

To see if you were successful adding ccache, check the generated toolchain file:
<syntaxhighlight lang="bash">
cat usr/x86_64-w64-mingw32.shared/share/cmake/mxe-conf.cmake
</syntaxhighlight>

it should look like this:
<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hooray/mxe/usr/x86_64-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
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 http://www.cmake.org/Bug/view.php?id=14075
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)

</syntaxhighlight>

to review ccache statistics, use (default cache is 1gb, so better raise this to ~3-5gb) :
<syntaxhighlight lang="bash">
$ ccache -s
</syntaxhighlight>

{{Note|At least on Ubuntu, openscenegraph.mk needs to be edited to add libgomp as a dependency for now}}
<syntaxhighlight lang="bash">
$ cd mxe
$ make openscenegraph --jobs=2 JOBS=2
</syntaxhighlight>

Dependencies should be resolved automatically, so that building osgearth should implicitly build osg first:
<syntaxhighlight lang="bash">
$ cd mxe
$ make osgearth --jobs=2 JOBS=2
</syntaxhighlight>

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

=== 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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}
{{#ev:youtube|ddYyH5CYhAo|400}}

=== Wednesday, May 29, 2015 : Simgear Shared support done (Thanks to {{usr|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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)}}

<syntaxhighlight lang="bash">$ find . -iname "*simgear*"
./i686-w64-mingw32.shared/lib/libSimGearCore.dll.a
./i686-w64-mingw32.shared/lib/libSimGearScene.dll.a
./i686-w64-mingw32.shared/installed/simgear
./i686-w64-mingw32.shared/include/simgear
./i686-w64-mingw32.shared/include/simgear/simgear_config.h
./i686-w64-mingw32.shared/share/SimGearCore
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig-release.cmake
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig.cmake
</syntaxhighlight>

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

{{#ev:youtube|mTHhHMlTSAo|400|left}} {{#ev:youtube|sfWVo5u_7lw|400|center}}

<syntaxhighlight lang=bash>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</syntaxhighlight>

=== 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)}}

[[File:Fgviewer under wine.png|400px|Screenshot of running FGViewer under Wine]]

== Issues ==
{{Note|This section contains sub-sections with open issues - which can be removed once they're solved/committed}}
=== OpenSceneGraph ===

* 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.

=== TerraGear ===

* 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 {{usr|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.

Talk:Building FlightGear - Cross Compiling

2015-06-20T03:34:19Z

Flyhigh: /* Simgear Test Crashes */

Talk:Building FlightGear - Cross Compiling

2015-06-19T15:43:05Z

Flyhigh: /* Simgear Test Crashes */

Talk:Building FlightGear - Cross Compiling

2015-06-17T02:28:03Z

Flyhigh: /* Simgear Test Crashes */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

: If we reach the stage where we succeed building/linking everything, but keep getting segfaults, we should definitely investigate prioritizing debugging support (e.g. using breakpad or some other mechanism that works sufficiently well (winedbg?)). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:25, 11 June 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== fgfs backtraces ==

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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

: is that also happening with the minimal startup profile being used ? and what about explicitly disabling scenery altogether ? If in doubt, please use the minimal startup profile and post your fgfs.log file so that we can take a look. It may be worthwhile to add a few SG_LOG() statements to the startup sequence in $FG_SRC/Main/fg_init.cxx to see what is going on - if that still isn't conclusive, I'd suggest to link in a debugging library like Breakpad which should be helpful to come up with a meaningful backtrace. Regarding fgviewer, what about the osgviewer/osgearthviewer binaries, do they work as expected ? I'd suggest that we add a table to the main article with all programs that are known to work/not work, so that we can more easily troubleshoot things in the time to come..

:: 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)

::: I would suggest running this inside gdb to get an annotated backtrace with source code shown - alternatively, we need to prioritize adding support for BreakPad, which should help with this. Also, is this using the minimal startup profile or just the default settings at ksfo ? If in doubt, I would also check that all sg/fg unit tests are working correctly, to see if that brings up any suspects. But for troubleshooting purposes, I would definitely first try the minimal startup profile as per the article (no multiplayer, scenery, terrasync etc)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:14, 9 June 2015 (EDT)

:::: I'v just read that link you posted about BreakPad, i like the idea of using a crash collecter to store the internal symbols of objects during compilation, so that it can be referenced against a mini-dump. it also support symbols generated in "OS X/Linux, DWARF" format, which is optimal for GCC. should we start to have a central server for crash collection? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:41, 11 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

: get into the CMake lists for that object that's failing to link, "present3D.exe". and define the missing libraries in "link_to_target". you would have to search google from which API these calling functions came from. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:11, 8 June 2015 (EDT)

:: I did that for one round, but that yielded another set of undefined references, as those libraries called other libraries. Is there any way to compile it other than completely specifying all dependencies? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:13, 8 June 2015 (EDT)

::: you could try to remove that target that's pulling tons of dependencies. if non of the other targets links with, maybe try to delete/edit its CMakeLists? alternatively you can disable these dependencies from the library. if these are GDAL related dependancies, then you can try to use a helper executable, like 'gdal-config.exe --dep-libs' and append these results into a variable, which is what i did for Terragear. https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc-terragear/src/cmake/FindGDAL.cmake (Line 27, find dependencies. Line 52, append to variable) -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:14, 8 June 2015 (EDT)

== excessive qoutes, user talk style ==
i suggest removing some of the qouting, i'd offer remove my qouting if no one minds, as i look to make our page cleaner, also what about some cleaner talk/reply style, any ideas? as excessive threading makes the talk unreadable in some instances -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:12, 8 June 2015 (EDT)

: sure, feel free to consider this "your" article and just go ahead - quotes are usually just intended to help "bootstrapping" new articles/projects, and should be phased out over time, unless some decisions/priorities need to be backed up by links to the corresponding statements - right now, the article has seen 1.8k views and dozens of edits, and it seems pretty safe to say that the article will stay around even if this effort should get stalled at some point, so unlike many other articles, this is already useful and documents and actual project.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 04:56, 9 June 2015 (EDT)

== repository relevant talk ==

a section, that contains a list will be created that you'll have to fill up to reflect what your working on. elements in the list are: owner, what it does/what feature it is supposed to create, which architichture, linking type, clone command + url. also, i suggest we rebase each feature from master-oldgcc for now(until we get a working GCC 5). -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:58, 11 June 2015 (EDT)

== Simgear Test Crashes ==

I've been under the assumption that the tests in Simgear are run automatically with every build. I didn't realize that thy had to be run manually (side-effect of using dh in Debian packaging, which does everything automatically for you). After running the tests, two tests crash, two tests go up to 100% CPU for at least a minute (before I killed those tests), one seemed to hang after completing successfully, and one seemed to have been called incorrectly (it was missing an argument). Below are the results:

* test-simgear_canvas_layout-canvas_layout.exe - Crash
* sg_pkgutil.exe - Crash, infinite recursion in what seems to be the Wine loader
* test_sock.exe - Hang after completion
* http_get.exe - 100% CPU
* http_svn.exe - 100% CPU
* decode_binobj.exe - Incorrect usage? Called with no arguments, when one argument was expected?

This was on x86_64-w64-mingw32.shared. I'll be compiling GDB soon, and hopefully, I can get a backtrace. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 15:40, 13 June 2015 (EDT)

: [https://gist.github.com/saiarcot895/8c032c0ebbc13da0e26f Here's] the stacktrace for test-simgear_canvas_layout-canvas_layout crashing. Don't know how useful it is... -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:28, 16 June 2015 (EDT)

Building FlightGear - Cross Compiling

2015-06-13T19:41:37Z

Flyhigh: /* Roadmap */ Update progress for toolchains

{{Non-stable|version=4.x|progress=30}}
{{-}}
{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|image = Fg-via-mxe-logo.png
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|70}} (compiles & runs OSG/osgEarth examples)
|maintainers = {{usr|Hamzaalloush}} and {{usr|Hooray}}
|developers = hamzaalloush, FlyHigh (since 05/2015)
|changelog =
* https://github.com/hamzaalloush/mxe-clone/commits/master-oldgcc
* https://github.com/saiarcot895/mxe/commits/master-oldgcc
}}

== News ==
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. [https://gist.github.com/saiarcot895/389c699af30a91d2774b 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".
-- [[User:Flyhigh|Flyhigh]] ([[User talk: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.

== Gallery ==
<gallery mode=packed widths=230px heights=230px>
OSG Earth.png|showing the symbolic osg earth :)
OSGEarth Boston Baseball.png|example what OSM buildings look like with OSG-Earth textures
</gallery>

== Roadmap ==
{{Note|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 simgear.mk for reference).}}

{| class="wikitable"
! Task !! Description !! Priority || People !! Progress
|-
| mxe 32-bit '''static''' tool-chain || progress of the '''static''' mxe i686-w64-mingw32-based tool-chain || [[File:Stars-1.png]] || {{Usr|Hamzaalloush}}|| {{Done}}
|-
| mxe 32-bit '''shared''' tool-chain || progress of the '''shared''' mxe i686-w64-mingw32-based tool-chain ||[[File:Stars-5.png]]|| {{Usr|Hamzaalloush}} & {{Usr|FlyHigh}}|| {{Progressbar|50}}
|-
| mxe 64-bit '''static''' tool-chain || progress of the '''static''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| mxe 64-bit '''shared''' tool-chain || progress of the '''shared''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| flightgear specific mxe tool-chain || mxe subset/progress of packages neccessary for the flightgear project, rather than the full 367 packages ||[[File:Stars-1.png]]||Hamzaalloush|| {{Progressbar|70}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] ||[[File:Stars-5.png]] || || {{Not done}}
|-
| leak checking support || add support for leak checking using [https://code.google.com/p/address-sanitizer/ Address Sanitizer] via <nowiki>-fsanitize=address -fno-omit-frame-pointer</nowiki> [https://github.com/sanhozay/fgbuild/blob/master/fgbuild#L82] ||[[File:Stars-3.png]]||...|| {{Not done}}

|-
| packages || provide binary mxe packages (deb/ppa) - e.g. via cmake/cpack [http://www.cmake.org/Wiki/CMake:CPackPackageGenerators] ||[[File:Stars-2.png]]||FlyHigh (?)|| {{Not done}}
|-
| VM || provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up ||[[File:Stars-2.png]]||Hooray|| {{Not done}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe ?? ||[[File:Stars-0.png]] || Hooray||{{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|Superbuild to support osgEarth]] ||priority || people|| {{Not done}}
|-
| build server || get the [[FlightGear Build Server]] updated to support mxe-based cross-builds ||mid-term||Jenkins maintainers|| {{Not done}}
|-
| Simgear portability || ensure Simgear is portable ''upstream'' for different platforms. (ex. Mingw64 is a different platform) ||[[File:Stars-5.png]]|| core developers|| {{Not done}}
|}

=== Dependencies ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Task !! Build System !! Description !! People !! Progress
|-
| plib.mk || autotools || provide mxe build scripts for plib || || {{Done}}
|-
| openrti.mk || cmake || add OpenRTI support ||Hamzaalloush|| {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] (probably, separate *.mk files for each) || || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone |||| {{Progressbar|80}}
|-
| simgear.mk ||cmake|| provide mxe build scripts for simgear || {{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| openscenegraph.mk support (shared library) ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Usr|Hamzaalloush}} & {{Usr|FlyHigh}}|| {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || || {{Progressbar|90}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth.mk]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) also see gdal issue discussed at [http://comments.gmane.org/gmane.comp.gnu.mingw.cross-env/3607] ||Hamzaalloush|| {{Progressbar|70}}
|-
| flightgear.mk ||cmake|| provide mxe build script for flightgear ||{{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| breakpad.mk ||cmake|| provide mxe build script for [https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad breakpad] Windows integration instructions at [https://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration] || Hooray || {{Not done}}
|-
| sigar.mk ||cmake|| provide mxe build script for [https://github.com/hyperic/sigar sigar -System Information Gatherer And Reporter] (cmake based, for better startup/run-time diagnostics on CPU/RAM utilization) || Hooray || {{Not done}}
|-
| Makefile SVN support || 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|| {{Progressbar|20}}
|-
| terragear.mk || cmake || build static monolithic TerraGear (compiles but segfaults) ||Hamzaalloush|| {{Progressbar|40}}
|}

== Goals ==
{{forum|81|FlightGear/osgEarth}}

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 [[Built-in Profiler|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:

{{FGCquote
|Is there somewhere an option to get a stacktrace when FG crashes?
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177395#p177395
|title=<nowiki>Re: FG Crash reported to Microsoft.</nowiki>
|author=<nowiki>Necolatis</nowiki>
|date=<nowiki>Sat Feb 16</nowiki>
}}
}}

{{FGCquote
| 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]]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177508#p177508
|title=<nowiki>Re: FG Crash reported to Microsoft. </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Feb 18</nowiki>
}}
}}

{{FGCquote
|BreakPad would be useful in getting higher quality crash reports
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192032#p192032
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
|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: [http://www.flightgear.org/forums/viewtopic.php?f{{=}}68&t{{=}}18942#p176669 http://www.flightgear.org/forums/viewto ... 42#p176669]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177561#p177561
|title=<nowiki>Re: Release 2.10 - not fixed bugs</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 19</nowiki>
}}
}}

{{FGCquote
|If we could teach the build server to build fgfs binaries with [http://code.google.com/p/google-breakpad/ 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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192031#p192031
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
| 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): [http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad http://code.google.com/p/google-breakpa ... thBreakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=176669#p176669
|title=<nowiki>Re: [Windows] FlightGear 2.10.0.0 RC1</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Feb 08</nowiki>
}}
}}

{{FGCquote
|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.
* [https://wiki.mozilla.org/Breakpad https://wiki.mozilla.org/Breakpad]
* [http://code.google.com/p/google-breakpad/ http://code.google.com/p/google-breakpad/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15078#p15078
|title=<nowiki> open source crash reporter</nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Mon Aug 11</nowiki>
}}
}}

{{FGCquote
|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/ [http://kb.mozillazine.org/Breakpad http://kb.mozillazine.org/Breakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15347#p15347
|title=<nowiki>Re: </nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Sat Aug 16</nowiki>
}}
}}

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) for testing/running and developing the mxe specific parts.

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

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

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

=== FlightGear ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Binary !! Status !! Description
|-
| fgjs || working (build/link & run-time) || "Joystick" on my laptop detected, but haven't checked the configuration process.
|-
| fgviewer || working || [[File:Fgviewer under wine.png|thumb|Screenshot of running FGViewer under Wine]]
|-
| fgfs || run-time error/segfault || [https://gist.github.com/saiarcot895/389c699af30a91d2774b crash information]
|-
| terragear || run-time error/segfault || still working on getting helpful backtrace, +sent msg to psadro_gm for questions on patches applied[https://github.com/hamzaalloush/mxe-clone/blob/b76befe28c42c4491a786bdc357a9ce3f02f47ad/src/terragear-1-mxe.patch]

|}

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

{{Startup Profile}}

=== Development branches ===

{| class="wikitable"
! Owner !! Feature !! Architichture !! Link type !! clone command !! binaries archive !! minidump/backtraces
|-
| {{usr|Hamzaalloush || Terragear || i686-w64-mingw32 || static || <syntaxhighlight lang="bash"> git clone -b master-oldgcc-terragear https://github.com/hamzaalloush/mxe-clone.git </syntaxhighlight> || TODO:terragear binaries || N/A
|-
| {{usr|Hamzaalloush || osgEarth || i686-w64-mingw32 || shared || <syntaxhighlight lang="bash"> git clone -b master-oldgcc-osgearth https://github.com/hamzaalloush/mxe-clone.git </syntaxhighlight> || TODO:osgEarth binaries || N/A

|}

=== WinDbg (debugging using Windows SDK) ===

* [http://blog.morlad.at/blah/mingw_postmortem Generating PDB Symbols] (cv2pdb to convert the DWARF debug info into PDB format, for use by Windows SDK)

=== WineDbg (debugging under WINE)===

* [http://wine-wiki.org/index.php/Winedbg Winedbg]
* [https://www.winehq.org/docs/winedev-guide/dbg-others Wine GDB mode]
* [http://mingw-cross.sourceforge.net/cross_debug.html Cross Debug on Linux and Wine]
* [http://ftp.winehq.org/pub/wine/docs/en/winedev-guide.html Wine Developer's Guide]

== 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

{{Note|This is a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package) - for autotools, refer to [https://github.com/saiarcot895/mxe/commit/e028a0a9f53c64266108177848eed90aea1958dd] or any other autoconf based packages}}

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

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

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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 ===
* [https://code.google.com/p/mupen64plus/wiki/CrossCompilingOnLinux Compiling Mupen64Plus from source code under Linux for Windows]
* [http://ejdb.org/doc/install/building.html Building native Windows libs on Linux]
* [https://www.93i.de/devzone/mxe-and-dynamic-linking mxe and dynamic linking using the MXE_TARGETS environment variable]
* [http://www.cs.cmu.edu/~soonhok/mxe-cross-compile-windows-binaries-on-ubuntu.html MXE: cross-compile windows binaries on ubuntu]

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

== Contributing ==
For now, please see:
* Requirements: http://mxe.cc/#requirements
* Getting started: http://mxe.cc/#tutorial
* Getting mxe: http://mxe.cc/#download
* Building mxe: http://mxe.cc/#usage
* Creating packages: http://mxe.cc/#creating-packages

Before building mxe, you should consider installing ccache first, which also requires adapting the pkgconf.mk file in mxe:
<syntaxhighlight lang="bash">
sudo apt-get install ccache
</syntaxhighlight>

Next, open src/pkgconf.mk 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).
<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..c1e30e4 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -52,9 +52,9 @@ define $(PKG)_BUILD_COMMON
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)'; \
- 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")'; \
</syntaxhighlight>

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:
<syntaxhighlight lang="cmake">
# http://stackoverflow.com/a/24305849
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
</syntaxhighlight>

<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..8de707b 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -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 '# http://stackoverflow.com/a/24305849'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)'; \
echo 'set(MSYS 1)'; \
echo 'set(BUILD_SHARED_LIBS $(if $(BUILD_SHARED),ON,OFF))'; \
echo 'set(LIBTYPE $(if $(BUILD_SHARED),SHARED,STATIC))'; \

</syntaxhighlight>

To see if you were successful adding ccache, check the generated toolchain file:
<syntaxhighlight lang="bash">
cat usr/x86_64-w64-mingw32.shared/share/cmake/mxe-conf.cmake
</syntaxhighlight>

it should look like this:
<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hooray/mxe/usr/x86_64-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
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 http://www.cmake.org/Bug/view.php?id=14075
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)

</syntaxhighlight>

to review ccache statistics, use (default cache is 1gb, so better raise this to ~3-5gb) :
<syntaxhighlight lang="bash">
$ ccache -s
</syntaxhighlight>

{{Note|At least on Ubuntu, openscenegraph.mk needs to be edited to add libgomp as a dependency for now}}
<syntaxhighlight lang="bash">
$ cd mxe
$ make openscenegraph --jobs=2 JOBS=2
</syntaxhighlight>

Dependencies should be resolved automatically, so that building osgearth should implicitly build osg first:
<syntaxhighlight lang="bash">
$ cd mxe
$ make osgearth --jobs=2 JOBS=2
</syntaxhighlight>

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

=== 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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}
{{#ev:youtube|ddYyH5CYhAo|400}}

=== Wednesday, May 29, 2015 : Simgear Shared support done (Thanks to {{usr|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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)}}

<syntaxhighlight lang="bash">$ find . -iname "*simgear*"
./i686-w64-mingw32.shared/lib/libSimGearCore.dll.a
./i686-w64-mingw32.shared/lib/libSimGearScene.dll.a
./i686-w64-mingw32.shared/installed/simgear
./i686-w64-mingw32.shared/include/simgear
./i686-w64-mingw32.shared/include/simgear/simgear_config.h
./i686-w64-mingw32.shared/share/SimGearCore
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig-release.cmake
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig.cmake
</syntaxhighlight>

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

{{#ev:youtube|mTHhHMlTSAo|400|left}} {{#ev:youtube|sfWVo5u_7lw|400|center}}

<syntaxhighlight lang=bash>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</syntaxhighlight>

=== 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)}}

[[File:Fgviewer under wine.png|400px|Screenshot of running FGViewer under Wine]]

== Issues ==
{{Note|This section contains sub-sections with open issues - which can be removed once they're solved/committed}}
=== OpenSceneGraph ===

* 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.

=== TerraGear ===

* 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 {{usr|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.

Talk:Building FlightGear - Cross Compiling

2015-06-13T19:40:20Z

Flyhigh: /* Simgear Test Crashes */ new section

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

: If we reach the stage where we succeed building/linking everything, but keep getting segfaults, we should definitely investigate prioritizing debugging support (e.g. using breakpad or some other mechanism that works sufficiently well (winedbg?)). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:25, 11 June 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== fgfs backtraces ==

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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

: is that also happening with the minimal startup profile being used ? and what about explicitly disabling scenery altogether ? If in doubt, please use the minimal startup profile and post your fgfs.log file so that we can take a look. It may be worthwhile to add a few SG_LOG() statements to the startup sequence in $FG_SRC/Main/fg_init.cxx to see what is going on - if that still isn't conclusive, I'd suggest to link in a debugging library like Breakpad which should be helpful to come up with a meaningful backtrace. Regarding fgviewer, what about the osgviewer/osgearthviewer binaries, do they work as expected ? I'd suggest that we add a table to the main article with all programs that are known to work/not work, so that we can more easily troubleshoot things in the time to come..

:: 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)

::: I would suggest running this inside gdb to get an annotated backtrace with source code shown - alternatively, we need to prioritize adding support for BreakPad, which should help with this. Also, is this using the minimal startup profile or just the default settings at ksfo ? If in doubt, I would also check that all sg/fg unit tests are working correctly, to see if that brings up any suspects. But for troubleshooting purposes, I would definitely first try the minimal startup profile as per the article (no multiplayer, scenery, terrasync etc)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:14, 9 June 2015 (EDT)

:::: I'v just read that link you posted about BreakPad, i like the idea of using a crash collecter to store the internal symbols of objects during compilation, so that it can be referenced against a mini-dump. it also support symbols generated in "OS X/Linux, DWARF" format, which is optimal for GCC. should we start to have a central server for crash collection? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:41, 11 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

: get into the CMake lists for that object that's failing to link, "present3D.exe". and define the missing libraries in "link_to_target". you would have to search google from which API these calling functions came from. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:11, 8 June 2015 (EDT)

:: I did that for one round, but that yielded another set of undefined references, as those libraries called other libraries. Is there any way to compile it other than completely specifying all dependencies? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:13, 8 June 2015 (EDT)

::: you could try to remove that target that's pulling tons of dependencies. if non of the other targets links with, maybe try to delete/edit its CMakeLists? alternatively you can disable these dependencies from the library. if these are GDAL related dependancies, then you can try to use a helper executable, like 'gdal-config.exe --dep-libs' and append these results into a variable, which is what i did for Terragear. https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc-terragear/src/cmake/FindGDAL.cmake (Line 27, find dependencies. Line 52, append to variable) -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:14, 8 June 2015 (EDT)

== excessive qoutes, user talk style ==
i suggest removing some of the qouting, i'd offer remove my qouting if no one minds, as i look to make our page cleaner, also what about some cleaner talk/reply style, any ideas? as excessive threading makes the talk unreadable in some instances -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:12, 8 June 2015 (EDT)

: sure, feel free to consider this "your" article and just go ahead - quotes are usually just intended to help "bootstrapping" new articles/projects, and should be phased out over time, unless some decisions/priorities need to be backed up by links to the corresponding statements - right now, the article has seen 1.8k views and dozens of edits, and it seems pretty safe to say that the article will stay around even if this effort should get stalled at some point, so unlike many other articles, this is already useful and documents and actual project.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 04:56, 9 June 2015 (EDT)

== repository relevant talk ==

a section, that contains a list will be created that you'll have to fill up to reflect what your working on. elements in the list are: owner, what it does/what feature it is supposed to create, which architichture, linking type, clone command + url. also, i suggest we rebase each feature from master-oldgcc for now(until we get a working GCC 5). -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:58, 11 June 2015 (EDT)

== Simgear Test Crashes ==

I've been under the assumption that the tests in Simgear are run automatically with every build. I didn't realize that thy had to be run manually (side-effect of using dh in Debian packaging, which does everything automatically for you). After running the tests, two tests crash, two tests go up to 100% CPU for at least a minute (before I killed those tests), one seemed to hang after completing successfully, and one seemed to have been called incorrectly (it was missing an argument). Below are the results:

* test-simgear_canvas_layout-canvas_layout.exe - Crash
* sg_pkgutil.exe - Crash, infinite recursion in what seems to be the Wine loader
* test_sock.exe - Hang after completion
* http_get.exe - 100% CPU
* http_svn.exe - 100% CPU
* decode_binobj.exe - Incorrect usage? Called with no arguments, when one argument was expected?

This was on x86_64-w64-mingw32.shared. I'll be compiling GDB soon, and hopefully, I can get a backtrace. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 15:40, 13 June 2015 (EDT)

Talk:Building FlightGear - Cross Compiling

2015-06-09T15:38:05Z

Flyhigh: /* fgfs backtraces */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== fgfs backtraces ==

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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

: is that also happening with the minimal startup profile being used ? and what about explicitly disabling scenery altogether ? If in doubt, please use the minimal startup profile and post your fgfs.log file so that we can take a look. It may be worthwhile to add a few SG_LOG() statements to the startup sequence in $FG_SRC/Main/fg_init.cxx to see what is going on - if that still isn't conclusive, I'd suggest to link in a debugging library like Breakpad which should be helpful to come up with a meaningful backtrace. Regarding fgviewer, what about the osgviewer/osgearthviewer binaries, do they work as expected ? I'd suggest that we add a table to the main article with all programs that are known to work/not work, so that we can more easily troubleshoot things in the time to come..

:: 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. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:38, 9 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

: get into the CMake lists for that object that's failing to link, "present3D.exe". and define the missing libraries in "link_to_target". you would have to search google from which API these calling functions came from. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:11, 8 June 2015 (EDT)

:: I did that for one round, but that yielded another set of undefined references, as those libraries called other libraries. Is there any way to compile it other than completely specifying all dependencies? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:13, 8 June 2015 (EDT)

::: you could try to remove that target that's pulling tons of dependencies. if non of the other targets links with, maybe try to delete/edit its CMakeLists? alternatively you can disable these dependencies from the library. if these are GDAL related dependancies, then you can try to use a helper executable, like 'gdal-config.exe --dep-libs' and append these results into a variable, which is what i did for Terragear. https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc-terragear/src/cmake/FindGDAL.cmake (Line 27, find dependencies. Line 52, append to variable) -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:14, 8 June 2015 (EDT)

== excessive qoutes, user talk style ==
i suggest removing some of the qouting, i'd offer remove my qouting if no one minds, as i look to make our page cleaner, also what about some cleaner talk/reply style, any ideas? as excessive threading makes the talk unreadable in some instances -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:12, 8 June 2015 (EDT)

: sure, feel free to consider this "your" article and just go ahead - quotes are usually just intended to help "bootstrapping" new articles/projects, and should be phased out over time, unless some decisions/priorities need to be backed up by links to the corresponding statements - right now, the article has seen 1.8k views and dozens of edits, and it seems pretty safe to say that the article will stay around even if this effort should get stalled at some point, so unlike many other articles, this is already useful and documents and actual project.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 04:56, 9 June 2015 (EDT)

Building FlightGear - Cross Compiling

2015-06-09T15:30:55Z

Flyhigh: /* Dependencies */

{{Non-stable|version=4.x|progress=30}}


{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|image = Fg-via-mxe-logo.png
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|70}} (compiles & runs OSG/osgEarth examples)
|maintainers = {{usr|hamzaalloush}} and {{usr|hooray}}
|developers = hamzaalloush, {{Usr|FlyHigh}} (since 05/2015)
|changelog =
* https://github.com/hamzaalloush/mxe-clone
* https://github.com/saiarcot895/mxe/tree/master-oldgcc
}}

== News ==
{{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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}

{{#ev:youtube|ddYyH5CYhAo|400|left}}{{#ev:youtube|mTHhHMlTSAo|400|center}}

== Gallery ==
<gallery mode=packed widths=230px heights=230px>
OSG Earth.png|showing the symbolic osg earth :)
</gallery>

== Roadmap ==
{{Note|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 simgear.mk for reference).}}

{| class="wikitable"
! Task !! Description !! Priority || People !! Progress
|-
| mxe 32-bit '''static''' tool-chain || progress of the '''static''' mxe i686-w64-mingw32-based tool-chain || [[File:Stars-1.png]] || Hamzaalloush|| {{Done}}
|-
| mxe 32-bit '''shared''' tool-chain || progress of the '''shared''' mxe i686-w64-mingw32-based tool-chain ||[[File:Stars-5.png]]|| Hamzaalloush|| {{Progressbar|40}}
|-
| mxe 64-bit '''static''' tool-chain || progress of the '''static''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| mxe 64-bit '''shared''' tool-chain || progress of the '''shared''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| flightgear specific mxe tool-chain || mxe subset/progress of packages neccessary for the flightgear project, rather than the full 367 packages ||[[File:Stars-1.png]]||Hamzaalloush|| {{Progressbar|70}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] ||[[File:Stars-5.png]] || || {{Not done}}
|-
| leak checking support || add support for leak checking using [https://code.google.com/p/address-sanitizer/ Address Sanitizer] via <nowiki>-fsanitize=address -fno-omit-frame-pointer</nowiki> [https://github.com/sanhozay/fgbuild/blob/master/fgbuild#L82] ||[[File:Stars-3.png]]||...|| {{Not done}}

|-
| packages || provide binary mxe packages (deb/ppa) - e.g. via cmake/cpack [http://www.cmake.org/Wiki/CMake:CPackPackageGenerators] ||[[File:Stars-2.png]]||FlyHigh (?)|| {{Not done}}
|-
| VM || provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up ||[[File:Stars-2.png]]||Hooray|| {{Not done}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe ?? ||[[File:Stars-0.png]] || Hooray||{{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|Superbuild to support osgEarth]] ||priority || people|| {{Not done}}
|-
| build server || get the [[FlightGear Build Server]] updated to support mxe-based cross-builds ||mid-term||Jenkins maintainers|| {{Not done}}
|}

=== Dependencies ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Task !! Build System !! Description !! People !! Progress
|-
| plib.mk || autotools || provide mxe build scripts for plib || || {{Done}}
|-
| openrti.mk || cmake || add OpenRTI support ||Hamzaalloush|| {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] (probably, separate *.mk files for each) || || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone |||| {{Progressbar|80}}
|-
| simgear.mk ||cmake|| provide mxe build scripts for simgear || {{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| openscenegraph.mk support (shared library) ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Usr|Hamzaalloush}} & {{Usr|FlyHigh}}|| {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || || {{Progressbar|90}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth.mk]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) also see gdal issue discussed at [http://comments.gmane.org/gmane.comp.gnu.mingw.cross-env/3607] ||Hamzaalloush|| {{Progressbar|70}}
|-
| flightgear.mk ||cmake|| provide mxe build script for flightgear ||{{Usr|FlyHigh}} -saiarcot895|| {{Progressbar|70}}
|-
| breakpad.mk ||cmake|| provide mxe build script for [https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad breakpad] Windows integration instructions at [https://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration] || Hooray || {{Not done}}
|-
| sigar.mk ||cmake|| provide mxe build script for [https://github.com/hyperic/sigar sigar -System Information Gatherer And Reporter] (cmake based, for better startup/run-time diagnostics on CPU/RAM utilization) || Hooray || {{Not done}}
|-
| Makefile SVN support || 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|| {{Progressbar|20}}
|-
| terragear.mk || cmake || build static monolithic TerraGear (compiles but segfaults) ||Hamzaalloush|| {{Progressbar|40}}
|}

== Goals ==
{{forum|81|FlightGear/osgEarth}}

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 [[Built-in Profiler|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:

{{FGCquote
|Is there somewhere an option to get a stacktrace when FG crashes?
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177395#p177395
|title=<nowiki>Re: FG Crash reported to Microsoft.</nowiki>
|author=<nowiki>Necolatis</nowiki>
|date=<nowiki>Sat Feb 16</nowiki>
}}
}}

{{FGCquote
| 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]]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177508#p177508
|title=<nowiki>Re: FG Crash reported to Microsoft. </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Feb 18</nowiki>
}}
}}

{{FGCquote
|BreakPad would be useful in getting higher quality crash reports
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192032#p192032
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
|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: [http://www.flightgear.org/forums/viewtopic.php?f{{=}}68&t{{=}}18942#p176669 http://www.flightgear.org/forums/viewto ... 42#p176669]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=177561#p177561
|title=<nowiki>Re: Release 2.10 - not fixed bugs</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 19</nowiki>
}}
}}

{{FGCquote
|If we could teach the build server to build fgfs binaries with [http://code.google.com/p/google-breakpad/ 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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192031#p192031
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 19</nowiki>
}}
}}

{{FGCquote
| 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): [http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad http://code.google.com/p/google-breakpa ... thBreakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=176669#p176669
|title=<nowiki>Re: [Windows] FlightGear 2.10.0.0 RC1</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Feb 08</nowiki>
}}
}}

{{FGCquote
|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.
* [https://wiki.mozilla.org/Breakpad https://wiki.mozilla.org/Breakpad]
* [http://code.google.com/p/google-breakpad/ http://code.google.com/p/google-breakpad/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15078#p15078
|title=<nowiki> open source crash reporter</nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Mon Aug 11</nowiki>
}}
}}

{{FGCquote
|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/ [http://kb.mozillazine.org/Breakpad http://kb.mozillazine.org/Breakpad]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15347#p15347
|title=<nowiki>Re: </nowiki>
|author=<nowiki>saturn5</nowiki>
|date=<nowiki>Sat Aug 16</nowiki>
}}
}}

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Idea ==
{{FGCquote
|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
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238158#p238158
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|I also think is better using free software tools to compile it and incidentally make it easier
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238176#p238176
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Catalanoic</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) for testing/running and developing the mxe specific parts.

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

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

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

=== FlightGear ===

{| class="wikitable"
! Task !! Description !! Priority || People !! Progress
|-
| mxe 32-bit '''static''' tool-chain || progress of the '''static''' mxe i686-w64-mingw32-based tool-chain || [[File:Stars-1.png]] || Hamzaalloush|| {{Done}}
|-
| mxe 32-bit '''shared''' tool-chain || progress of the '''shared''' mxe i686-w64-mingw32-based tool-chain ||[[File:Stars-5.png]]|| Hamzaalloush|| {{Progressbar|40}}
|-
| mxe 64-bit '''static''' tool-chain || progress of the '''static''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| mxe 64-bit '''shared''' tool-chain || progress of the '''shared''' mxe x86_64-w64-mingw32-based tool-chain || || {{Usr|FlyHigh}} -saiarcot895|| progress
|-
| flightgear specific mxe tool-chain || mxe subset/progress of packages neccessary for the flightgear project, rather than the full 367 packages ||[[File:Stars-1.png]]||Hamzaalloush|| {{Progressbar|70}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] ||[[File:Stars-5.png]] || || {{Not done}}
|-
| leak checking support || add support for leak checking using [https://code.google.com/p/address-sanitizer/ Address Sanitizer] via <nowiki>-fsanitize=address -fno-omit-frame-pointer</nowiki> [https://github.com/sanhozay/fgbuild/blob/master/fgbuild#L82] ||[[File:Stars-3.png]]||...|| {{Not done}}

|-
| packages || provide binary mxe packages (deb/ppa) - e.g. via cmake/cpack [http://www.cmake.org/Wiki/CMake:CPackPackageGenerators] ||[[File:Stars-2.png]]||FlyHigh (?)|| {{Not done}}
|-
| VM || provide virtual appliance with mxe pre-configured and valid sg/fg build environments set up ||[[File:Stars-2.png]]||Hooray|| {{Not done}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe ?? ||[[File:Stars-0.png]] || Hooray||{{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|Superbuild to support osgEarth]] ||priority || people|| {{Not done}}
|-
| build server || get the [[FlightGear Build Server]] updated to support mxe-based cross-builds ||mid-term||Jenkins maintainers|| {{Not done}}
|}

=== Dependencies ===
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 <nowiki>-DCMAKE_BUILD_TYPE=DEBUG</nowiki> 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'''.}}

{| class="wikitable"
! Binary !! Status !! Description
|-
| fgjs || working (build/link & run-time) || "Joystick" on my laptop detected, but haven't checked the configuration process.
|-
| fgviewer || working || [[File:Fgviewer under wine.png|thumb|Screenshot of running FGViewer under Wine]]
|-
| fgfs || run-time error/segfault || [https://gist.github.com/saiarcot895/389c699af30a91d2774b crash information]
|-
| terragear || run-time error/segfault || still working on getting helpful backtrace, +sent msg to psadro_gm for questions on patches applied[https://github.com/hamzaalloush/mxe-clone/blob/b76befe28c42c4491a786bdc357a9ce3f02f47ad/src/terragear-1-mxe.patch]

|}

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

{{Startup Profile}}

=== WinDbg (debugging using Windows SDK) ===

* [http://blog.morlad.at/blah/mingw_postmortem Generating PDB Symbols] (cv2pdb to convert the DWARF debug info into PDB format, for use by Windows SDK)

=== WineDbg (debugging under WINE)===

* [http://wine-wiki.org/index.php/Winedbg Winedbg]
* [https://www.winehq.org/docs/winedev-guide/dbg-others Wine GDB mode]
* [http://mingw-cross.sourceforge.net/cross_debug.html Cross Debug on Linux and Wine]
* [http://ftp.winehq.org/pub/wine/docs/en/winedev-guide.html Wine Developer's Guide]

== 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

{{Note|This is a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package) - for autotools, refer to [https://github.com/saiarcot895/mxe/commit/e028a0a9f53c64266108177848eed90aea1958dd] or any other autoconf based packages}}

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

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

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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 ===
* [https://code.google.com/p/mupen64plus/wiki/CrossCompilingOnLinux Compiling Mupen64Plus from source code under Linux for Windows]
* [http://ejdb.org/doc/install/building.html Building native Windows libs on Linux]
* [https://www.93i.de/devzone/mxe-and-dynamic-linking mxe and dynamic linking using the MXE_TARGETS environment variable]
* [http://www.cs.cmu.edu/~soonhok/mxe-cross-compile-windows-binaries-on-ubuntu.html MXE: cross-compile windows binaries on ubuntu]

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

{{FGCquote
| 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. 
 
now comes the fun part, installing the much sought after shared building toolchain, and i'm having g++ linking errors produced by mingw-g++ upstream, one that i managed to fix and i'm currently dealing with further errors... after that, i don't think build a OSG shared library is so out of reach
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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! :) 
 
i have a local branch that i keep all the various commits and bandaids that i apply in order to make an FG friendly build environment, and who knows, i might fork the MXE project and provide a minimum build environment tailored for FG if they didn't accept my patches for it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

== Contributing ==
For now, please see:
* Requirements: http://mxe.cc/#requirements
* Getting started: http://mxe.cc/#tutorial
* Getting mxe: http://mxe.cc/#download
* Building mxe: http://mxe.cc/#usage
* Creating packages: http://mxe.cc/#creating-packages

Before building mxe, you should consider installing ccache first, which also requires adapting the pkgconf.mk file in mxe:
<syntaxhighlight lang="bash">
sudo apt-get install ccache
</syntaxhighlight>

Next, open src/pkgconf.mk 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).
<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..c1e30e4 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -52,9 +52,9 @@ define $(PKG)_BUILD_COMMON
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)'; \
echo 'set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)'; \
- 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")'; \
</syntaxhighlight>

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:
<syntaxhighlight lang="cmake">
# http://stackoverflow.com/a/24305849
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
</syntaxhighlight>

<syntaxhighlight lang="diff">
diff --git a/src/pkgconf.mk b/src/pkgconf.mk
index 9a23619..8de707b 100644
--- a/src/pkgconf.mk
+++ b/src/pkgconf.mk
@@ -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 '# http://stackoverflow.com/a/24305849'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)'; \
+ echo 'SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)'; \
echo 'set(MSYS 1)'; \
echo 'set(BUILD_SHARED_LIBS $(if $(BUILD_SHARED),ON,OFF))'; \
echo 'set(LIBTYPE $(if $(BUILD_SHARED),SHARED,STATIC))'; \

</syntaxhighlight>

To see if you were successful adding ccache, check the generated toolchain file:
<syntaxhighlight lang="bash">
cat usr/x86_64-w64-mingw32.shared/share/cmake/mxe-conf.cmake
</syntaxhighlight>

it should look like this:
<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hooray/mxe/usr/x86_64-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
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 http://www.cmake.org/Bug/view.php?id=14075
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)

</syntaxhighlight>

to review ccache statistics, use (default cache is 1gb, so better raise this to ~3-5gb) :
<syntaxhighlight lang="bash">
$ ccache -s
</syntaxhighlight>

{{Note|At least on Ubuntu, openscenegraph.mk needs to be edited to add libgomp as a dependency for now}}
<syntaxhighlight lang="bash">
$ cd mxe
$ make openscenegraph --jobs=2 JOBS=2
</syntaxhighlight>

Dependencies should be resolved automatically, so that building osgearth should implicitly build osg first:
<syntaxhighlight lang="bash">
$ cd mxe
$ make osgearth --jobs=2 JOBS=2
</syntaxhighlight>

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

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

=== Wednesday, May 29, 2015 : Simgear Shared support done (Thanks to {{usr|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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)}}

<syntaxhighlight lang="bash">$ find . -iname "*simgear*"
./i686-w64-mingw32.shared/lib/libSimGearCore.dll.a
./i686-w64-mingw32.shared/lib/libSimGearScene.dll.a
./i686-w64-mingw32.shared/installed/simgear
./i686-w64-mingw32.shared/include/simgear
./i686-w64-mingw32.shared/include/simgear/simgear_config.h
./i686-w64-mingw32.shared/share/SimGearCore
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig-release.cmake
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig.cmake
</syntaxhighlight>

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

<syntaxhighlight lang=bash>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</syntaxhighlight>

{{#ev:youtube|sfWVo5u_7lw|400|left}} [[File:OSGEarth Boston Baseball.png|400px|center]]

== Issues ==
{{Note|This section contains sub-sections with open issues - which can be removed once they're solved/committed}}
=== OpenSceneGraph ===

* 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.

=== TerraGear ===

* 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 {{usr|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: {{FGCquote |Small, stable, incremental changes are preferable to larger monolithic changes to ease review. |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34183645/ |title=<nowiki>[Flightgear-devel] Policy Document and V4.X Roadmap</nowiki> |author=<nowiki>Stuart Buchanan</nowiki> |date=Jun 7th, 2015 }}}}, adhering to the FG Global 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.

File:Fgviewer under wine.png

2015-06-09T15:29:18Z

Flyhigh: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot of running FGViewer under Wine (compiled through MXE for i686-w64-mingw32.shared)}}
|date=2015-06-09 08:28:14
|source={{own}}
|author=[[User:Flyhigh|Flyhigh]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

Talk:Building FlightGear - Cross Compiling

2015-06-08T15:13:31Z

Flyhigh: /* OSG static build */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== fgfs backtraces ==

::: 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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

: is that also happening with the minimal startup profile being used ? and what about explicitly disabling scenery altogether ? If in doubt, please use the minimal startup profile and post your fgfs.log file so that we can take a look. It may be worthwhile to add a few SG_LOG() statements to the startup sequence in $FG_SRC/Main/fg_init.cxx to see what is going on - if that still isn't conclusive, I'd suggest to link in a debugging library like Breakpad which should be helpful to come up with a meaningful backtrace. Regarding fgviewer, what about the osgviewer/osgearthviewer binaries, do they work as expected ? I'd suggest that we add a table to the main article with all programs that are known to work/not work, so that we can more easily troubleshoot things in the time to come..

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

: get into the CMake lists for that object that's failing to link, "present3D.exe". and define the missing libraries in "link_to_target". you would have to search google from which API these calling functions came from. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:11, 8 June 2015 (EDT)

:: I did that for one round, but that yielded another set of undefined references, as those libraries called other libraries. Is there any way to compile it other than completely specifying all dependencies? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:13, 8 June 2015 (EDT)

Talk:Building FlightGear - Cross Compiling

2015-06-08T04:05:04Z

Flyhigh: /* Status 06/2015 ? */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

::: 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". Also, running fgjs seems to work, as the "joystick" on my laptop (the hard drive) is detected, and fgviewer launches, but the earth is just a gray sphere. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:05, 8 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

Talk:Building FlightGear - Cross Compiling

2015-06-08T03:52:36Z

Flyhigh: /* OSG static build */ new section

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

::perhaps the segfaults are related to using 32-bit cinaries with the new WS/2.0 scenery?? just an idea -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:33, 6 June 2015 (EDT)

:: is there any way to share the broken stuff so that we can take a look - i.e. how about committing broken stuff to a separate topic branch, so that people can more easily follow what is going on and help find a solution ? Alternatively, let's exchange the corresponing logs on the wiki. Obviously, it would help to know if any of the build/run-time issues are affected by type of build and/or the target/library built. My suggestion would be to start with self-contained tests/demos unrelaeted to FG, and maybe switch to running FG/SG unit tests afterwards ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:49, 6 June 2015 (EDT)

:I'm now on i686-w64-mingw32.static, trying to build terragear all of a sudden. got some commits up on a new master-oldgcc-terragear branch containing patches for geos(fix exported symbols), boost(force static), and a terragear.mk with mingw specific patches that makes it compile 90% of the way. for last status updates overall, {{usr|Flyhigh}} seems to interact pretty well the MXE community and got some changes commited to upstream[https://github.com/mxe/mxe/pull/698][https://github.com/mxe/mxe/pull/699]. i agree with the compile log's idea, let us make another topic for that, as long as we keep them even if solved for later reference. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:21, 6 June 2015 (EDT)

:: Thank you for trying to get useful things merged upstream - regarding those crashes, if you can, please share your gdb backtraces using either the wiki or some form of pastebin. If that is not an option, I would suggest to prioritize working out a useful way to add better debugging support for those binaries (e.g. using Breakpad) so that we don't need to use gdb for getting a backtrace. Regarding PortableXDR: where is that being used currently, would it make sense to reuse the tinyXDR implementation in SG/FG (mp) or at least look at it for reference/patching ? If you think those segfaults may be scenery related, I would suggest to consider using the minimal startup profile to check that theory, i.e. by excluding scenery from being loaded altogether. Trying to build TG seems like another useful test case, so maybe we should add this to the roadmap, because it will pull in tons of other SG/FG dependencies. For troubleshooting segfaults, I would suggest to focus first on simple binaries, e.g. unit tests in SimGear and/or $FG_SRC/utils (e.g. stuff like fgviewer, fgjs etc). Maybe we could update the wiki to present a more up to date list of recent developments and/or required work that lies ahead of us ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:33, 6 June 2015 (EDT)

== OSG static build ==

I'm unable to build a static OpenSceneGraph. When building the present3D application, the linking stage fails, because it wants all of the static libraries used (directly and indirectly), not just the directly used ones. I've uploaded the ending of the build log into [https://gist.github.com/saiarcot895/24d59f7b0a282fb28720 a gist]. Any suggestions? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:52, 7 June 2015 (EDT)

Talk:Building FlightGear - Cross Compiling

2015-06-06T15:42:53Z

Flyhigh: /* Status 06/2015 ? */

== Build Errors ==
is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:22, 18 May 2015 (EDT)

: sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:38, 18 May 2015 (EDT)

:: yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:52, 18 May 2015 (EDT)

: It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
: It could also potentially help similar endeavors later on.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:38, 19 May 2015 (EDT)

== Required OSG Plugins ==

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 18:58, 18 May 2015 (EDT)

:: sounds like a plan, I'd use <nowiki>grep -R</nowiki> and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [https://github.com/mxe/mxe/issues/11#issuecomment-13474413]. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:06, 18 May 2015 (EDT)

== Minimizing the needed number of MXE packages ==
the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 21:16, 22 May 2015 (EDT)

== mxe specific tool chain ==

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the [[Superbuild]] afterwards. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:55, 23 May 2015 (EDT)

:: as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the [[Superbuild]], i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected [[Building_using_CMake_-_Windows#Directory_tree]]. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:40, 23 May 2015 (EDT)

: I do agree, I have also seen optional dependencies being "defaulted" to "yes" for the sake of simplicity - while ffmpeg isn't currently needed by SG/FG, a few FG devs (especially those doing UAV stuff) have been contemplating to support ffmpeg-based video streaming in FG at some point (see [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|supporting streaming in FG]] for details/references), so I guess it would be better to identify such osg/mxe issues (I think some osg examples require ffmpeg), and make the corresponding dependency optional by adding proper dependency resolution, e.g. by using the corresponding OSG magic to detect such dependencies (osg-config, or even just cmake configuration flags). I do however agree that it makes sense to first get a basic build working, and only look at all the other optional stuff later on - we will need some kind of solution to deal with those anyway (think fgcom, profiler, osgEarth, HLA/RTI etc).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:49, 24 May 2015 (EDT)

:: if that's the case, i might ignore this for now and keep ffmpeg, unless it gives error and then i'll proceed with a basic build. in static-mingw, until now only one OSG plugin has been making problems which was when building 'gdal', which i assume necessary for osg-earth, I’ll write the specifics in the Issues/OSG topic when i'm done so we can resolve it later. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:35, 24 May 2015 (EDT)

: true, gdal is needed for osgEarth, but would also be useful for supporting mxe-based building of TerraGear --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:55, 28 May 2015 (EDT)

== 3rd party deps/directory structure ==

I still need to check the Superbuild/CMakeLists.txt files, but I assume that those assumptions are not Windows specific, but primarily MSVC specific - so may not even be applicable to a gcc-based cross-compiler ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 13:54, 24 May 2015 (EDT)

:yes your right! :-) after i checked, this was to resolve MSVC linking to 3rd parties. that dir structure might not even be needed, still, i think it is a good idea to at least compile the respective versions of those 3rd party dependencies as provided in the fgmeta/3rdparty branch. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 19:30, 24 May 2015 (EDT)

:: it definitely is a good idea, but looking at the two CMakeLists.txt in SG/FG, those 3rd party deps are there mainly for those systems not providing "system-wide" versions of those - so we could just as well review existing mxe *.mk files and directly add support for the equivalent libs to mxe, to ensure that there both options are provided. As far as I understand, system-libs would be chosen by default on *nix platforms anyway, so we could just as well ignore 3rd party deps when doing cross-compilation, by simply using the corresponding mxe equivalents for those. Overall, I think that "3rdparty.zip" is a workaround addressing shortcomings in the Windows build process - so if it is easier to directly build the proper packages as part of mxe, I would consider doing that instead, as it feels more "natural" to me. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:33, 28 May 2015 (EDT)

::: certainly this was my thought process recently too. as FG is known to compile against development version of those. so i will leave them as is, and probably even remove that objective from the roadmap. it makes sense to continue unless we have problems. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:28, 28 May 2015 (EDT)

== Testing & Development ==

it would be helpful if there was automation step involved, to routinely cross-compile crucial MXE element for current status, as for instance when certain MXE package "$(PKG)_URL" elements becomes unavailable upstream. sort of like a Jenkins implementation. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 05:29, 27 May 2015 (EDT)

: I've been in touch with a few contributors - unless we can get the [[FlightGear Build Server]] maintainers involved, we do have at least one volunteer to provide hosting on a VPS, where mxe and jenkins could be set up, with full root access provided as well. Alternatively, the OpenSuse Build Service (OBS) does provide Jenkins integration, too: https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process
: Given all the recent progress, and the increasing number of contributors wanting to help with different aspects of this effort, I do think that it would make sense to either register an [https://build.opensuse.org/ OBS] account, and/or, sign up for gcc compile farm access: https://gcc.gnu.org/wiki/CompileFarm - any preferences ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:30, 28 May 2015 (EDT)

:: no i do not. which infrastructure is more easier to use? i think i can leave this decision in the hands of someone with more experience than me, so please feel free to suggest any ideas or someone to consult/contribute? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:27, 28 May 2015 (EDT)

: The "gcc compile farm" is just a bunch of dedicated servers reachable via SSH where you can download/build and run stuff, so fairly easy to use for people familiar with Linux - the OBS is a different beast, and pretty sophisticiated, too - i.e. it can even be used to automatically package up software for different distros automatically (think deb, ppa, rpm etc), and it comes with tons of support and documentation, too - while also being possible to integrate with Jenkins based CI servers and a few IDEs. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:50, 28 May 2015 (EDT)

:: OBS can be used for building/creating packages for pretty much all distros/package managers, and it will also handle hosting (which might be useful given that a binary mxe package may easily be ~3-4 gb in size). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:11, 30 May 2015 (EDT)

== simgear.mk/fgfs.mk ==

i think i can prototype something right now for this, should i parallel with ({{Usr|FlyHigh}} -saiarcot895? what is his status right now? -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: having a prototype (for SimGear headless) would make sense in my opinion, and it coud be used as a template for other (non-headless) stuff, including both, SG & FG as a whole, but also other dependencies (think openrti). So given that SimGear is the only common dependency here, I would suggest to prototype a well-commented example and get this committed, so that others can take a look and learn from it, e.g. to help refine SG/FG support and come up with modules for optional dependencies. The [[Superbuild]] would be a different beast anyway, because it is trying to do everything (including the source check outs), so that would require some thinking - and having experience with dedicated simgear.mk and flightgear.mk files should come in very handy for that.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:47, 28 May 2015 (EDT)

:: I have a preliminary simgear.mk that has most of the dependencies and the building, but haven't reached testing stage yet because I'm having trouble compiling netcdf. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:47, 28 May 2015 (EDT)

::: Well, I found at least half of the problem: portablexdr has an empty build command for x86_64-w64-mingw32, which I was building in. Also, I've uploaded the simgear.mk to [https://github.com/saiarcot895/mxe/tree/master-oldgcc here] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:21, 28 May 2015 (EDT)

:::: yeah, some clean-up required for these x86_64-w64-mingw32 entries there. i suggest removing them as i did removing $(PKG)_BUILD_SHARED complety whenever i get a [no-build] result for shared package. nice work on getting the preliminary simgear.mk up, i'll test with it, but let me know when you are finished working that x86_64-w64-mingw32 toolchain to produce openscenegraph, please commit your progress for each package fixed. also, if you want i can merge that simgear.mk commit into my fork, or you do a pull request? whichever you prefer. i'll be following your repo as a remote. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:22, 29 May 2015 (EDT)

::::: I've switched to i686-w64-mingw32.shared for now, only because everything else is set up there. I'll test x86_64 once I have Simgear up and running. Simgear currently fails to get past CMake, so I'll be working on that today. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:04, 29 May 2015 (EDT)

:: 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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)

::: great job, also set the 3rd party dependancies to 100% when your done with FG build. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 15:16, 29 May 2015 (EDT)

:::: Flightgear now builds and starts up (after a few changes to the Simgear build script), but crashes sometime around initializing scenery. Also, FgCom is disabled currently due to problems with libiax. Also, Simgear is built in C++11 mode, while Flightgear is built in the default (C++89 or C++99, I think) mode; this could be one of the reasons why Flightgear is crashing. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:31, 30 May 2015 (EDT)

== Superbuild ==
This isn't relevant at the moment, but referring to the Superbuild related comments above: it seems we could end up with a viable workaround by figuring out if/how and where those *.mk files are getting the value for <nowiki>-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'</nowiki> from - i.e. '''CMAKE_TOOLCHAIN_FILE''' specifically, and directly reuse that in the Superbuild (need to check if that'd work). But if it's too much of a hassle, let's just focus on *.mk files for starters. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:06, 28 May 2015 (EDT)

:sure, it's stored in mxe/usr/${triplet-name}/share/cmake/mxe-conf.cmake, i'm sorry if this is not the place to include here, but here is it's contents anyway, autotools has similar implementation with $(MXE_CONFIGURE_OPTS), for autotools that is contained in the Makefile IIRC. mxe-conf.cmake: -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 17:14, 28 May 2015 (EDT)

<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)
set(MSYS 1)
set(BUILD_SHARED_LIBS ON)
set(LIBTYPE SHARED)
set(CMAKE_BUILD_TYPE Release)
set(CMAKE_FIND_ROOT_PATH /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_C_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gcc)
set(CMAKE_CXX_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-g++)
set(CMAKE_Fortran_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-gfortran)
set(CMAKE_RC_COMPILER /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-windres)
set(CMAKE_MODULE_PATH "/home/hamza/build/hamza-mxe/src/cmake" ${CMAKE_MODULE_PATH}) # For mxe FindPackage scripts
set(CMAKE_INSTALL_PREFIX /home/hamza/build/hamza-mxe/usr/i686-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 http://www.cmake.org/Bug/view.php?id=14075
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/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-pkg-config)
set(HDF5_C_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5cc)
set(HDF5_CXX_COMPILER_EXECUTABLE /home/hamza/build/hamza-mxe/usr/bin/i686-w64-mingw32.shared-h5c++)
set(Boost_THREADAPI "win32")
set(QT_QMAKE_EXECUTABLE /home/hamza/build/hamza-mxe/usr/i686-w64-mingw32.shared/qt/bin/qmake)

</syntaxhighlight>

: thanks, you spared me quite a bit of searching here - I think this should already be a good way to play with getting the [[Superbuild]] to work at some point, without it necessarily having to invoke/involve mxe *.mk files. Basically, we would need the equivalent of some kind of '''mxe-config''' script that provides the corresponding path for such keys (e.g. the CMAKE_TOOLCHAIN_FILE) so that this can be reused elsewhere, without having to hard-code any paths.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:19, 28 May 2015 (EDT)

:: hi, so all you need is an provoking script that initialize that file/set var as a standalone? And then it should be straightforward to adopt for the supper build? Then what happens to this project, is this just an exercise for cross-compiling FG? Or merely an extension to the Super build like d&c currently -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:39, 29 May 2015 (EDT)

: even "just" *.mk based cross compilation would be useful already - however, it would obviously be platform specific, while the Superbuild is pretty much guaranteed to stay around, and to be maintained in the future - i.e. due to it not being specific to any single platform/os or compiler, and due to it being used by the Jenkins build server. All the dependencies would still need to build/work correctly - so I guess it would be more difficult to use/adapt the Superbuild directly. Once mxe is able to build FG and all deps using *.mk files, we should strive to review all necessary additions/patches and try to get those merged upstream (mxe, sg, fg etc) - the Superbuild would be nice to support because that would mean that mxe-based cross compilation would be handled by the same front-end. But even just having a handful of *.mk files would be very useful, i.e. to provide FG/osgEarth binaries to Windows-based end users.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:35, 29 May 2015 (EDT)

ok Hooray, i'll probably do a miniture adoption of building a small package with mingw64 using the requirements learned from $(MXE_CONFIGURE_OPTS) in the superbuild, do you have any progress? i'm looking for something to do meanwhile saiarcot895 are building for Flightgear static. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:44, 3 June 2015 (EDT)

== Project Focus ==

:: which is exactly why we started this whole initiative, to provide osgEarth binaries first and foremost. now, on the subject of getting these package changes reviewed and merged into upstream/master... i don't think that's realistic, given that i did my own thing to make it work *on my distribution*, so as it stands, for the sake of progress, we should focus on our branch, it's very clear to see how each plugin/dependancy was built from .mk files to check for regressions, my fork is so off the upstream it's not even funny, converting some packages to CMake and reverting to stable GCC among others. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:16, 29 May 2015 (EDT)

: ok, I see - I was mainly referring to required OSG/SG and FG level patches to ensure that those are merged (think CMakeLists.txt stuff). Regarding mxe, I would suggest to gather all related patches/branches and establish this as a "fork" intended to support compilation of OSG-based applications like FlightGear, which would mean that other OSG projects/developers may sooner or later be interested in using such an "mxe.osg" fork. Equally, I would hope that using the OBS would help us do some more testing on non Ubuntu distros eventually (I am also on Ubuntu 14.xx) to ensure that "mxe.osg" works across a handful of main distros. For now, the focus should probably be coming up with an osgearth.mk module to see if the OSG integration is able to link other OSG apps, i.e. SG/FG afterwards. Once that is the case, we can review poweroftwo's batch file and create separate simgear-osgearth.mk and flightgear-osgearth.mk files for FG/osgEarth. The Superbuild shouldn't be a priority right now, but I will make sure to check what is required to get that working. Thanks so far everybody, great job !--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 30 May 2015 (EDT)

:: Based on what I've seen, it probably will be possible to merge it into upstream (the commits might need some cleaning up), but the main blocker here is that the bug in GCC 5.1 that's blocking the compilation of OSG (or was it another library?) needs to be fixed. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:27, 30 May 2015 (EDT)

::: it was for BOOST not able to link with stdlibc++ in GCC 5.1 when trying to define the std::codecvt_byname facet. see, [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030] [http://pastebin.com/HcizTVkg] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 11:47, 30 May 2015 (EDT)

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

== Debugging ==

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)

::: MXE can build GDB for Windows, which will help a little (at least for users familiar with debugging in Linux/Unix) in debugging. It works fairly well; the only issue I've encountered so far is that you can't interrupt a running program using Ctrl-C. That being said, though, these builds don't have any debugging symbols in them, so if someone wants to use GDB, they'll need to modify the .mk files. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 12:23, 30 May 2015 (EDT)

: I don't think there's any conflicting priorities so far - the backtrace can be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)

== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)

: thank you for all that you'v done Hooray, we appreciate it!! let's make this an example of complete wiki collaboration :) btw your welcome to add yourself to the developers!!

== .deb packaging ==

what should the .deb package consist of? a freeze of a successful build with all it's packages? it's totaling 3 GB's right now on my system. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:35, 28 May 2015 (EDT)

: right, I guess we do have different target audiences: those just wanting to cross-compile FG (without all the setup overhead) would definitely benefit most from everything pre-compiled included, so I would suggest to keep things simple for now and just turn the whole shebang into a deb/ppa package to ensure that FG (including all deps) can be built. I can also help and turn this into a virtual appliance for VirtualBox (possibly including a working fg source tree) But I think we only need to look into this once the other items can be scratched off from the roadmap - i.e. once SG/FG actually build & link correctly. In the meantime, it should probably be safe to assume that all parties interested in this, are able to get/set up and use mxe from your github branch ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:44, 28 May 2015 (EDT)

:: yup, you can clone this from my branch and get it going with only 'git clone -b master-oldgcc https://github.com/hamzaalloush/mxe-clone.git' && 'make openscenegraph', but i do not guarantee all packages will be working on non-Ubuntu system. i have a back-up rig that has Debian Wheezy in it, and was unable to compile with it. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:50, 28 May 2015 (EDT)

== Reported Segfaults ==

Can you provide a backtrace ? what about the other programs/unit tests (e.g. in SG: via make tests) - do they work correctly, or not ? (also, was this on an actual Windows installation or just using WINE/qemu?) For testing, you can also use various binaries in /utils (e.g. fgviewer)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:28, 30 May 2015 (EDT)

==MXE central repository==
now as it stands, we have two seperate repo's, one for {{usr|Flyhigh}} and the other for myself, so to not make any conflicting merges, do we create a new one? or do we adopt Flyhigh's? as it seems to be more complete than mine. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:30, 30 May 2015 (EDT)

: right, for now, I guess it makes sense to agree on a single repo, and add volunteers/contributors as committers - while asking people to help maintain the wiki article, so that others can more easily follow everything. I don't have any preference regarding which repo to use, so I trust your judgement. Besides, how long does it take for you to build everything ? Should we already look around for compile farm/OBS access (those systems typically having at least ~12 cores and ~32gb of RAM) ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 30 May 2015 (EDT)

:: i'm ready to remove my repository and base my work on Flyhigh's if he's ok, we are already done with FG, the mk files are there. even if not (seg-fault free). {{usr|Flyhigh}} gonna have to report if it was by C++11 compilation(else might be core issue) [...] -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)
: ok, sounds like a plan --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:06, 30 May 2015 (EDT)

== ccache & distcc ==
as for the other question, it takes about 2 hours on an i5. we can look to the compile farm when doing testing other distribution i guess. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

btw, on a single computer you can use ccache to cache previously compiled object files (which will take up several gb of disk space), if you have access to other computers on the LAN, you can also use distcc (possibly in conjunction with ccache). For me, using just ccache helps speed up OSG/SG/FG compilation significantly, because most files are unlikely to have been modified at all - so can usually be reused "as is". --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:03, 30 May 2015 (EDT)

== OSG & osgEarth ==
Given that OSG now builds correctly, I would suggest to come up with a dedicated <code>osgearth.mk</code> file for testing purposes, which we can also use as a template for SG/FG <code>flightgear-osgearth.mk</code> afterwards, while also preparing support for the osgearth branch poweroftwo has been maintaining. In addition, osgearth comes with a bunch of osgearth applications that should be useful for testing purposes (OSG vs. osgearth support, both being required for linking) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:32, 29 May 2015 (EDT)

: good post-coffee (+3 GMT) afternoon :) sure, i'll look into that since {{usr|Flyhigh}} is unto the sf/fg mk files for now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 04:25, 29 May 2015 (EDT)

it remains for me to make the osg-earth.mk(have some undefined references right now), than to get FG/SG with osgearth-patch. see [https://gitlab.com/poweroftwo/flightgear-osgearth], that'll be a matter of download and compile only as poweroftwo has rebased his work on release/3.4, and that's already working for us now. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 14:51, 30 May 2015 (EDT)

== dcmtk Static Build ==

I was trying to do a static build of Flightgear, which, along the way, needs dcmtk. However, it's searching for Wine and the C++ runtime, which is failing for me. How did you get past that? -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:39, 1 June 2015 (EDT)

: did you try to revert to autotools version[https://github.com/mxe/mxe/blob/master/src/dcmtk.mk]? it works for i686-w64-mingw32.static target(just tested now). for i686-w64-mingw32.shared support, i did CMake conversion [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk.mk], and apply patch for finding 3rd party deps since dcmtk wasn't using FIND_PACKAGE in CMake/3rdparty.cmake, because it assumes we are on Windows [https://github.com/hamzaalloush/mxe-clone/blob/master-oldgcc/src/dcmtk-1-fix_missing_libs.patch#L130]. my suggestion is to revert to autotools -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 09:26, 2 June 2015 (EDT)

:: Ok, so I did revert to the autotools version, but was wondering if the CMake version worked for you for a static build. I'm now getting an unusual linker error in building netcdf. It can't find a reference to, for example, _imp__SDfileinfo, but _SDfileinfo is present in libmfhdf.a. Any clue what might be going on here? I'm suspecting it has something to do with the symbol visibility. - [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:21, 2 June 2015 (EDT)

::: references to _imp suggests that it's looking for a 'shared' import library symbol. example ./lib/libmfhdf.dll.a, which does not exist in your tree. so find out why netcdf is linking with shared references? see: http://pastebin.com/FkF2nFRS -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:41, 2 June 2015 (EDT)

== porting to GCC 5.1 ==
well, there has been some progress to the missing exports for libstdc++, one of GCC's main developers has started arranging a patch after few other reporting with successful attemps freezing of the missing functions to an older version. a few other issues have arrisen after more investigation for this bug, so should we port back to GCC 5.1 when the patch is complete? is it worth it? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 20:21, 3 June 2015 (EDT)

: MXE has committed a [https://github.com/mxe/mxe/commit/6947d3245f9c76d9124a4c4f3c164154a75f3f62 patch] to fix building with GCC 5. I haven't tested it yet, though. Currently, I'm working on upstreaming the changes here (slowly), so that we can then work on the main upstream branch (with GCC 5 compatibility). -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 22:35, 4 June 2015 (EDT)

:: I should have noticed the following beforehand: [https://github.com/mxe/mxe/pull/534 534], [https://github.com/mxe/mxe/pull/611 611], [https://github.com/mxe/mxe/pull/612 612] -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 23:27, 4 June 2015 (EDT)

== Status 06/2015 ? ==

Hi guys, what's the latest news/status, and where do we find your changes/commits ? And what is currently missing/broken, i.e. needs investigating ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:34, 6 June 2015 (EDT)

:Haven't gotten anywhere on the crash with i686 shared, so I'm working on the static side of things and also slowly upstreaming our changes here. Also, 64-bit is starting to be painful (mainly because of portablexdr). I'm now building i686 static and hoping that that at least builds. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 11:42, 6 June 2015 (EDT)

Talk:Building FlightGear - Cross Compiling

2015-06-05T03:27:49Z

Flyhigh: /* porting to GCC 5.1 */

Talk:Building FlightGear - Cross Compiling

2015-06-05T02:35:52Z

Flyhigh: /* porting to GCC 5.1 */

Talk:Building FlightGear - Cross Compiling

2015-06-02T15:21:07Z

Flyhigh: /* dcmtk Static Build */

Talk:Building FlightGear - Cross Compiling

2015-06-02T01:39:16Z

Flyhigh: /* dcmtk Static Build */ new section

Talk:Building FlightGear - Cross Compiling

2015-05-30T16:23:36Z

Flyhigh: /* Project Focus */

Talk:Building FlightGear - Cross Compiling

2015-05-30T15:31:10Z

Flyhigh: /* simgear.mk/fgfs.mk */

Talk:Building FlightGear - Cross Compiling

2015-05-30T15:27:50Z

Flyhigh: /* Project Focus */

Building FlightGear - Cross Compiling

2015-05-30T15:25:31Z

Flyhigh: /* Dependencies */ Simgear and Flightgear now load (but crash)

{{Non-stable|version=4.x|progress=30}}
{{Stub}}

{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|40}}
|maintainers = {{usr|hamzaalloush}} and {{usr|hooray}}
|developers = hamzaalloush, {{Usr|FlyHigh}} (since 05/2015)
|changelog =
* https://github.com/hamzaalloush/mxe-clone
* https://github.com/saiarcot895/mxe/tree/master-oldgcc
}}

== News ==
{{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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}

{{#ev:youtube|ddYyH5CYhAo|400|left}}{{#ev:youtube|mTHhHMlTSAo|400|center}}

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

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Idea ==
{{FGCquote
|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
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238158#p238158
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|I also think is better using free software tools to compile it and incidentally make it easier
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238176#p238176
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Catalanoic</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package):

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

cd '$(1).build' && cmake '$(1)' \
-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)' \
-DENABLE_BAR=ON \
-DENABLE_BAZ=OFF

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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.

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

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

=== Wednesday, May 29, 2015 : Simgear Shared support done (Thanks to {{usr|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%. -- [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 14:16, 29 May 2015 (EDT)}}

<syntaxhighlight lang="bash">$ find . -iname "*simgear*"
./i686-w64-mingw32.shared/lib/libSimGearCore.dll.a
./i686-w64-mingw32.shared/lib/libSimGearScene.dll.a
./i686-w64-mingw32.shared/installed/simgear
./i686-w64-mingw32.shared/include/simgear
./i686-w64-mingw32.shared/include/simgear/simgear_config.h
./i686-w64-mingw32.shared/share/SimGearCore
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig-release.cmake
./i686-w64-mingw32.shared/share/SimGearCore/SimGearCoreConfig.cmake
</syntaxhighlight>

{{FGCquote
| 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. 
 
now comes the fun part, installing the much sought after shared building toolchain, and i'm having g++ linking errors produced by mingw-g++ upstream, one that i managed to fix and i'm currently dealing with further errors... after that, i don't think build a OSG shared library is so out of reach
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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! :) 
 
i have a local branch that i keep all the various commits and bandaids that i apply in order to make an FG friendly build environment, and who knows, i might fork the MXE project and provide a minimum build environment tailored for FG if they didn't accept my patches for it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

== Issues ==
=== OpenSceneGraph ===

* 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.

== Roadmap ==
{{Note|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}}

{| class="wikitable"
! Task !! Description !! Progress
|-
| 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 || {{Progressbar|40}}
|-
| flightgear specific mxe tool-chain || progress of packages neccessary for the flightgear project, rather than the full 367 packages || {{Progressbar|70}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe ?? || {{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] || {{Not done}}

|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|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}}
|}

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

{| class="wikitable"
! Task !! Build System !! Description !! Progress
|-
| plib.mk || autotools || provide mxe build scripts for plib || {{Done}}
|-
| openrti.mk || cmake || add OpenRTI support || {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] (probably, separate *.mk files for each) || {{Not done}}
|-
| simgear.mk ||cmake|| provide mxe build scripts for simgear ({{Usr|FlyHigh}} -saiarcot895 '''hint:focus on [[Building_using_CMake#Optional_Features|SG headless]] first''') || {{Progressbar|70}}
|-
| openscenegraph.mk support (shared library) ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || {{Progressbar|90}}
|-
| flightgear.mk ||cmake|| provide mxe build scripts for flightgear || {{Progressbar|70}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth.mk]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone || {{Progressbar|80}}
|-
| Makefile SVN support || 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 || {{Progressbar|20}}
|}

{{Building}}
[[Category:Core developer documentation]]

Talk:Building FlightGear - Cross Compiling

2015-05-29T18:16:41Z

Flyhigh: /* simgear.mk/fgfs.mk */

Building FlightGear - Cross Compiling

2015-05-29T17:57:56Z

Flyhigh: /* Dependencies */

{{Non-stable|version=4.x|progress=30}}
{{Stub}}

{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|40}}
|maintainers = {{usr|hamzaalloush}} and {{usr|hooray}}
|developers = hamzaalloush, {{Usr|FlyHigh}} (since 05/2015)
|changelog = https://github.com/hamzaalloush/mxe-clone
}}

== News ==
{{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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}

{{#ev:youtube|ddYyH5CYhAo|400|left}}{{#ev:youtube|mTHhHMlTSAo|400|center}}

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Idea ==
{{FGCquote
|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
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238158#p238158
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|I also think is better using free software tools to compile it and incidentally make it easier
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238176#p238176
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Catalanoic</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package):

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

cd '$(1).build' && cmake '$(1)' \
-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)' \
-DENABLE_BAR=ON \
-DENABLE_BAZ=OFF

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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.

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

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

{{FGCquote
| 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. 
 
now comes the fun part, installing the much sought after shared building toolchain, and i'm having g++ linking errors produced by mingw-g++ upstream, one that i managed to fix and i'm currently dealing with further errors... after that, i don't think build a OSG shared library is so out of reach
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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! :) 
 
i have a local branch that i keep all the various commits and bandaids that i apply in order to make an FG friendly build environment, and who knows, i might fork the MXE project and provide a minimum build environment tailored for FG if they didn't accept my patches for it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

== Issues ==
=== OpenSceneGraph ===

* 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.

== Roadmap ==
{{Note|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}}

{| class="wikitable"
! Task !! Description !! Progress
|-
| 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 || {{Progressbar|40}}
|-
| flightgear specific mxe tool-chain || progress of packages neccessary for the flightgear project, rather than the full 367 packages || {{Progressbar|70}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe || {{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] || {{Not done}}

|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|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}}
|}

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

{| class="wikitable"
! Task !! Build System !! Description !! Progress
|-
| plib || autotools || provide mxe build scripts for plib || {{Done}}
|-
| openrti || cmake || add OpenRTI support || {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] || {{Not done}}
|-
| simgear ||cmake|| provide mxe build scripts for simgear ({{Usr|FlyHigh}} -saiarcot895 '''hint:focus on [[Building_using_CMake#Optional_Features|SG headless]] first''') || {{Progressbar|50}}
|-
| osg shared library support ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || {{Progressbar|90}}
|-
| flightgear ||cmake|| provide mxe build scripts for flightgear || {{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone || {{Progressbar|80}}
|-
| Makefile SVN support || 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 || {{Progressbar|20}}
|}

{{Building}}
[[Category:Core developer documentation]]

Building FlightGear - Cross Compiling

2015-05-29T17:56:28Z

Flyhigh: /* Dependencies */

{{Non-stable|version=4.x|progress=30}}
{{Stub}}

{{Infobox subsystem
|name = Cross Compiling FlightGear on Linux for Windows using mxe (mingw64)
|started = 05/2015
|description = Windows binaries created using a cross compiler on Linux
|status = Under active development as of 05/2015 {{Progressbar|40}}
|maintainers = {{usr|hamzaalloush}} and {{usr|hooray}}
|developers = hamzaalloush, {{Usr|FlyHigh}} (since 05/2015)
|changelog = https://github.com/hamzaalloush/mxe-clone
}}

== News ==
{{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! -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 13:25, 28 May 2015 (EDT) }}

{{#ev:youtube|ddYyH5CYhAo|400|left}}{{#ev:youtube|mTHhHMlTSAo|400|center}}

== Background ==
{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238025#p238025
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Apr 06</nowiki>
}}
}}

{{FGCquote
|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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238202#p238202
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|I agree completely, introducing cross-compiling support could be a good idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238222#p238222
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

== Idea ==
{{FGCquote
|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
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238158#p238158
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|I also think is better using free software tools to compile it and incidentally make it easier
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238176#p238176
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Catalanoic</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

== Testing & Development ==
{{Main article|Howto:Cross platform development}}

We may benefit from getting access to the [https://en.opensuse.org/Build_Service Suse build service] (or the [https://gcc.gnu.org/wiki/CompileFarm gcc compile farm]) 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 the full set of targets that can be passed as arguments to the GNU make utility, visit: http://mxe.cc/#usage

for example, a simple:
<syntaxhighlight lang="bash">
$ cd mxe/
$ make
</syntaxhighlight>

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

packages are contained in index.html as html table elements, the name of the package is the value of html subtype "package":
<syntaxhighlight lang="html5">
<tr>
<td class="package">simgear</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">SimGear - Simulator Construction Tools</a></td>
</tr>
<tr>
<td class="package">fgfs</td>
<td class="website"><a href="https://sourceforge.net/projects/flightgear/">FlightGear Flight Simulator</a></td>
</tr>
</syntaxhighlight>

=== 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:
<syntaxhighlight lang="bash">
$ make fgfs
</syntaxhighlight>

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}}

a [[Developing using CMake|CMake-based]] template (e.g. for adding support for [[OpenSceneGraph]], osgEarth, [[SimGear]] and [[FlightGear]] would look like this (with [[Building_using_CMake#Build_Targets|configuration options]] obviously being specific to the corresponding package):

<syntaxhighlight lang="make">
# This file is part of MXE: http://mxe.cc
# This file specifies how to build: FOO http://www.foo.org
# See index.html for further information.

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

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

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

cd '$(1).build' && cmake '$(1)' \
-DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)' \
-DENABLE_BAR=ON \
-DENABLE_BAZ=OFF

$(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef
</syntaxhighlight>

{{Main article|http://mxe.cc/#creating-packages Creating mxe packages}}

=== Applying Patches ===

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

<syntaxhighlight lang="bash">

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
</syntaxhighlight>

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.

=== Project inspiration ===
{{DeQuote}}

{{FGCquote
|Your best would then be, mxe: [http://mxe.cc/ http://mxe.cc/] 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238162#p238162
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|mxe is based on mingw, and comes with all libraries required for cross-compilation included, including even OSG 3.x
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239267#p239267
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Apr 17</nowiki>
}}
}}

{{FGCquote
|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/c7deb709fd4779e778a564c2bf83781486926850 https://github.com/mxe/mxe/commit/c7deb ... 1486926850] 
 
(this even includes Qt5 support) 
 
The cross-compiler used is [http://mingw-w64.yaxm.org/doku.php http://mingw-w64.yaxm.org/doku.php] 
 
Detalis on setting up mxe are at: [http://mxe.cc/#tutorial http://mxe.cc/#tutorial]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238178#p238178
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Apr 08</nowiki>
}}
}}

{{FGCquote
|plib is already supported in master (see /src/plib.mk) 
 
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.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=239512#p239512
|title=<nowiki>Re: Help me! Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Apr 18</nowiki>
}}
}}

== Status ==

=== 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. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 16:06, 27 May 2015 (EDT)}}

<pre>
$ find . -iname "*osg*"
./i686-w64-mingw32.shared/bin/libosgText.dll
./i686-w64-mingw32.shared/bin/libosgTerrain.dll
./i686-w64-mingw32.shared/bin/libosgVolume.dll
./i686-w64-mingw32.shared/bin/libosgGA.dll
./i686-w64-mingw32.shared/bin/libosgDB.dll
./i686-w64-mingw32.shared/bin/libosgParticle.dll
./i686-w64-mingw32.shared/bin/libosg.dll
./i686-w64-mingw32.shared/bin/libosgShadow.dll
./i686-w64-mingw32.shared/bin/libosgPresentation.dll
./i686-w64-mingw32.shared/bin/libosgManipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bvh.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_exr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lwo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgtgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dxf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pic.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ive.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgmanipulator.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_p3d.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_jp2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ogr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ktx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_qfont.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osganimation.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ffmpeg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_png.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gta.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_logo.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dot.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trk.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_sdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pnm.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_stl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgtext.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_vtf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_obj.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pvr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgfx.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bsp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_rgb.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_openflight.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_txf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_hdr.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_bmp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dw.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_lws.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_dicom.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgwidget.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osga.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_md2.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tiff.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3ds.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_3dc.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gif.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_curl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgshadow.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_x.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_mdl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_normals.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pov.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_serializers_osgsim.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_zip.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_shp.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_pdf.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_trans.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_tgz.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ac.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_ply.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_gdal.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgterrain.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_cfg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgparticle.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osg.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_deprecated_osgvolume.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_scale.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_glsl.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_osgviewer.dll
./i686-w64-mingw32.shared/bin/osgPlugins-3.2.1/mingw_osgdb_revisions.dll
./i686-w64-mingw32.shared/bin/libosgQt.dll
./i686-w64-mingw32.shared/bin/libosgAnimation.dll
./i686-w64-mingw32.shared/bin/libosgSim.dll
./i686-w64-mingw32.shared/bin/libosgUtil.dll
./i686-w64-mingw32.shared/bin/libosgViewer.dll
./i686-w64-mingw32.shared/bin/libosgWidget.dll
./i686-w64-mingw32.shared/bin/libosgFX.dll
./i686-w64-mingw32.shared/lib/libosgViewer.dll.a
./i686-w64-mingw32.shared/lib/libosgPresentation.dll.a
./i686-w64-mingw32.shared/lib/libosgTerrain.dll.a
./i686-w64-mingw32.shared/lib/libosgManipulator.dll.a
./i686-w64-mingw32.shared/lib/libosg.dll.a
./i686-w64-mingw32.shared/lib/libosgAnimation.dll.a
./i686-w64-mingw32.shared/lib/libosgQt.dll.a
./i686-w64-mingw32.shared/lib/libosgWidget.dll.a
./i686-w64-mingw32.shared/lib/libosgParticle.dll.a
./i686-w64-mingw32.shared/lib/libosgText.dll.a
./i686-w64-mingw32.shared/lib/libosgDB.dll.a
./i686-w64-mingw32.shared/lib/libosgSim.dll.a
./i686-w64-mingw32.shared/lib/libosgVolume.dll.a
./i686-w64-mingw32.shared/lib/libosgUtil.dll.a
./i686-w64-mingw32.shared/lib/libosgFX.dll.a
./i686-w64-mingw32.shared/lib/libosgGA.dll.a
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgDB.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgViewer.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgGA.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgShadow.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgSim.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osg.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgAnimation.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgTerrain.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgUtil.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgWidget.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgVolume.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgText.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgQt.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgParticle.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgManipulator.pc
./i686-w64-mingw32.shared/lib/pkgconfig/openscenegraph-osgFX.pc
./i686-w64-mingw32.shared/lib/libosgShadow.dll.a
./i686-w64-mingw32.shared/include/osgShadow
./i686-w64-mingw32.shared/include/osgViewer
./i686-w64-mingw32.shared/include/osgWidget
./i686-w64-mingw32.shared/include/osgVolume
./i686-w64-mingw32.shared/include/osgSim
./i686-w64-mingw32.shared/include/osgParticle
./i686-w64-mingw32.shared/include/osgGA
./i686-w64-mingw32.shared/include/osgUtil
./i686-w64-mingw32.shared/include/osgManipulator
./i686-w64-mingw32.shared/include/osgText
./i686-w64-mingw32.shared/include/osgFX
./i686-w64-mingw32.shared/include/osg
./i686-w64-mingw32.shared/include/osgAnimation
./i686-w64-mingw32.shared/include/osgDB
./i686-w64-mingw32.shared/include/osgDB/DotOsgWrapper
./i686-w64-mingw32.shared/include/osgTerrain
./i686-w64-mingw32.shared/include/osgPresentation
./i686-w64-mingw32.shared/include/osgQt
</pre>

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

{{FGCquote
| 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. 
 
now comes the fun part, installing the much sought after shared building toolchain, and i'm having g++ linking errors produced by mingw-g++ upstream, one that i managed to fix and i'm currently dealing with further errors... after that, i don't think build a OSG shared library is so out of reach
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

{{FGCquote
|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! :) 
 
i have a local branch that i keep all the various commits and bandaids that i apply in order to make an FG friendly build environment, and who knows, i might fork the MXE project and provide a minimum build environment tailored for FG if they didn't accept my patches for it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|date=<nowiki>Thu May 14</nowiki>
}}
}}

== Issues ==
=== OpenSceneGraph ===

* 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.

== Roadmap ==
{{Note|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}}

{| class="wikitable"
! Task !! Description !! Progress
|-
| 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 || {{Progressbar|40}}
|-
| flightgear specific mxe tool-chain || progress of packages neccessary for the flightgear project, rather than the full 367 packages || {{Progressbar|70}}
|-
| [[Superbuild]] || Update the CMake Superbuild to support mxe || {{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]]-patched FG || there's a Windows batch file created by poweroftwo demonstrating what needs to be done, see [http://forum.flightgear.org/viewtopic.php?f=81&t=23404] || {{Not done}}

|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] || update the [[Superbuild#Maintenance|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}}
|}

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

{| class="wikitable"
! Task !! Build System !! Description !! Progress
|-
| plib || autotools || provide mxe build scripts for plib || {{Done}}
|-
| openrti || cmake || add OpenRTI support || {{Progressbar|30}}
|-
| optional ||cmake|| add support for [[Building_using_CMake#Optional_Features|optional dependencies]] || {{Not done}}
|-
| simgear ||cmake|| provide mxe build scripts for simgear ({{Usr|FlyHigh}} -saiarcot895 '''hint:focus on [[Building_using_CMake#Optional_Features|SG headless]] first''') || {{Progressbar||50}}
|-
| osg shared library support ||cmake|| improve/fix up OpenSceneGraph 3.x support (i.e. shared,non-static, builds using plugins) || {{Progressbar|90}}
|-
| osg examples/demos ||cmake|| ensure that all OSG examples build/link properly via <nowiki>-DBUILD_OSG_EXAMPLES=ON</nowiki> and <nowiki>-DBUILD_OSG_APPLICATIONS=ON</nowiki> || {{Progressbar|90}}
|-
| flightgear ||cmake|| provide mxe build scripts for flightgear || {{Not done}}
|-
| [[Building FlightGear with osgEarth Integration|osg-earth]] ||cmake|| add dedicated <code>osgearth.mk</code> module for mxe (ensure that the examples are working properly) || {{Not done}}
|-
| 3rdParty || mxe || ensure 3rd party dependencies are built in the toolchain, and merge their *.mk packages in the clone || {{Progressbar|80}}
|-
| Makefile SVN support || 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 || {{Progressbar|20}}
|}

{{Building}}
[[Category:Core developer documentation]]

Talk:Building FlightGear - Cross Compiling

2015-05-29T15:04:09Z

Flyhigh: /* simgear.mk/fgfs.mk */

Talk:Building FlightGear - Cross Compiling

2015-05-29T02:21:27Z

Flyhigh: /* simgear.mk/fgfs.mk */

Talk:Building FlightGear - Cross Compiling

2015-05-29T01:47:03Z

Flyhigh: /* simgear.mk/fgfs.mk */

Switching default texture format to DDS

2014-09-05T11:58:29Z

Flyhigh: /* NVIDIA open source driver */ Add entry from Google+

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===

FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|GeForce GT 540M
|331.82
|{{yes}}
|Gijs
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|}

=== NVIDIA open source driver ===

{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|{{yes}}
|Flyhigh/saiarcot895
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|Saga
|}

== Sample test ==

=== DDS Test at the airport of Orio (Bergamo - Italy) ===

[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this.

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==

=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===

{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}
=== Precomputed mipmaps ===

{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==

{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==

{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}
== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==

{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

Switching default texture format to DDS

2014-09-04T19:45:24Z

Flyhigh: /* Intel OpenSource driver */

{{Note|
{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}
}}

{{WIP}}

== Feedback needed - should Flightgear switch the defaults to dds format for terrain texturing? ==

=== What is this about? ===

The FG development team is considering to switch the format for terrain textures from png to dds. This would offer a number of significant advantages:

* dds is a compressed format, hence the download size of the FG base package may be decreased
* compressed dds can be directly used by many graphics cards, reducing also GPU memory consumption
* dds stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* the resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use dds for these reasons.

However, the dds compression algorithm is patented, which means that it is not readily available for OpenSource graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process dds, for older graphics cards there are non-patented workarounds available which decompress the dds on the software level). The development team is concerned about making the Flightgear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in dds format with the 3.4 release, and then phase out the use of png textures.

== What would we need? ==

Flightgear already provides the simple option to test a dds texture set. If you are running on Linux and use an OpenSource graphics driver, please take 5 minutes to help during your next FG session:

* Open the dialog under View -> Rendering

* Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'

* Press 'Okay' - FG will reload the terrain

* Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic colors or other rendering artifacts, your system may have problems with dds.

* Change back to the texture scheme you like best

* Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphis drivers ==
{{Note|Please add your own hardware/results here !}}

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|GeForce GT 540M
|331.82
|{{yes}}
|Gijs
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|}

=== NVIDIA OpenSource driver ===

=== Intel proprietary driver ===

=== Intel OpenSource driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|{{yes}}
|Flyhigh/saiarcot895
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|}

=== ATI/AMD OpenSource driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|Saga
|}

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 (points made by Mathias)==

=== Portability Concerns ===
These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours
is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise.

I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files
cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL
driver can use this and displays this fine.

Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in
effect rules out the majority of users as intel cannot work with these files.

(*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics
boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins).

I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some
better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way.

I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures?

this is the reason for the (warning) message. If your machine would refuse to display this you, developing that, would probably just say 'nice try, but it does not work' before you check in something. In the case it displays fine, you probably say 'it works here, so I assume it works also for others, lets do'.
And the message tells you, 'despite of just seeing this working on this current machine, it does not work for others'.

Seriously, I think plenty people not being on this list today and probably never will be in touch with anybody here, will run into this issue.
People here are those few guys from the power users that want to develop this stuff.

Your driver will display this fine. So, in the end I do not care if it is 'your particular video driver' that does
not like this. You will just see this in the best case as the models look wrong, and in the worst case fgfs just crashes the driver if these textures
are used. What I really care about is that these files are expected not to work on a huge amount of graphics boards out there. The point is to tell people doing
textures that they should omit compression so that this message disapears.

The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed
mipmaps - and being able to display fine with any driver/gpu.

=== Approaches ===
Ideas raised by Mathias in 2012 [https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg35523.html]:

I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that.
And in fact this will not happen to the open source drivers before something about 2020 because of patent issues.

Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed?
The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think?

I hope that we can get rid of the compression. Can somebody with the apropriate tools convert the compressed textures to non compressed ones? That could still be dds, but dds without these compressions that produce the warning. So no problem with cubemaps in dds as long as the
compression is not there. Then *everybody* is again able to use this stuff.

* Just do not use the patented compression stuff. The precomputed mipmaps could probably do the job of avoiding the hangs (hopefully? to be checked?). May be we could lower disk space usage by providing a dds.gz or similar wrapper?

* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution.

* Implement some kind of image lookup order that knows if the compressed files could be handled or not. On loading an image in case of available compression
first try to find a dds file with the same name of the original one. That involves some 'magic' which often leads to problems but that could at least work.

Other ideas? Also may be creative ones?

Next step is to make sure that compression is not required to avoid the hangs. My favorite bet would be that then the new configure option regarding texture compression needs to be set to none.

=== Precomputed mipmaps ===
points made by Mathias in 2012[https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg37848.html]:

Could we do dds files without compression but with precomputed mipmaps?

So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine?

"precompute the mipmaps in the loader. IIRC tests with some of the guys suffering from this problem, providing premipmapped but uncompressed dds files had helped to get a fluent viewer. The argument against providing these dds files in general was that these files are really huge because of not including any compression and having all the mipmaps. But that means we could at the point where the warning happens compute the mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be
used to do this I think (or something similar not requireing a context). This one is an imported version of the original glu function that is included in
osg for running on an EGL stack which no longer provides GLU. That is take the image scale this to the 1st mipmap, take the 1.st mipmap and scale this to the 2. mipmap and so forth.
This would have the advantage that the png's do not deviate from the dds files over time."

computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation.
Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU.

Doing that differently will provide some overhead that could be kept at a minimum I think:
For the disk usage, I think gzip compressing these will work sufficiently fine. Ram usage of the images should not hurt too much. Sure the images are bigger
in memory. But fgfs is not just about images - far from that. On the GPU, you can still use compression for the textures as the internal
format. This is what flightgear tries to do if the extension is supported (checked by osg).

The major point is that there are several ways that use slightly more resources to get around this problem.
But once the patented compression is on disk, there is *no* way back for people not having this feature.

If you have better ideas that do not rule out intel and the oss drivers, you are welcome!

On linux this should work as long as you have zlib installed which could be regarded as a system library there. Can we rely on zlib being compield into our osg distributions on win32? We do need zlib in any case, it's mostly about teaching osg that it finds our zlib on configure and build the gz plugin.

FredB implemented a mipmap control and generation tool in effects when he last updated the urban shader. For the moment, it relies on hardware when the average operator is used for all texture channels but it could easily be modified to compute all mipmap on the CPU. look the <mipmap-control> effect option and
mipmap.[ch]xx in SG material lib

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}
== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

FlightGear Git: data developers

2014-07-24T00:40:43Z

Flyhigh: /* Bundle */ Update for bundle updates 9-11

{{Git}}
Anyone contributing data to FlightGear, like aircraft models, dialogs or textures, is a '''data developer'''. This article helps those in setting up a correct workflow, to ease the inclusion of their work into the simulator.

== Preparations ==
The steps described in this section are only required once, at the initialization of your development environment.

=== Cloning the repository ===
The first thing to do as a prospective developer is to [https://gitorious.org/users/new register at Gitorious] if you haven't already done so. This will enable you to publish your edits and have them incorporated into the main project.

After logging in, you can create a personal "clone" of the data repository. This clone is where you will be working in, without touching the main repository. To create a clone, navigate to the fgdata repository on https://gitorious.org/fg/ and click the [http://gitorious.org/fg/fgdata/clone Clone repository] button. In general the default name is fine, but you can change it to whatever you like. Gitorious will now clone the data repository. Due to the size of our repository, this can take some time.

=== Obtaining the data ===
Before you can start editing, you first need to retrieve the data to your computer. There are two ways to do this. At the time of writing the data repository is over 5 GB. Continuing an interrupted cloning of a repository is not supported within Git. Therefore, if you have a slow or unstable connection to the internet, it is recommended to [[#Bundle|download the bundle]].

For both approaches, Git must be installed. There is a lot of software available, but the following are often used:
* '''Mac:''' [http://code.google.com/p/git-osx-installer/ Git for OS X]
* '''Windows:''' [http://msysgit.github.io/ msysGit]

==== Single clone ====
# Create a directory on your computer where you'll be storing the data.
# Change into that folder.
# Clone the repository with the following command. This will create a <tt>/fgdata</tt> subfolder and put all the contents of the repository in there.
#:<code><nowiki>git clone git://gitorious.org/fg/fgdata.git</nowiki></code>

==== Bundle ====
For the FlightGear-data there is a [http://www.kernel.org/pub/software/scm/git/docs/git-bundle.html git-bundle] (snapshot) [http://mxchange.org:23456/file?info_hash=%BF%FF%AB%0C%16%BF%8Eg%B8%A0%CFw%01%0A%5D%8F%3F%81%96y torrent] ([http://mxchange.org:23456/ tracker]; [http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle.md5 md5]|[http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle.sha1 sha1]|[http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle.sha512 sha512]) available. This way you can resume interrupted downloads. After unpacking it only a comparatively small amount of data has to be transferred from the git server to synchronize your repository. Also download the fgdata-update-*.bundle updates linked in the [http://mxchange.org:23456/ tracker]. See also the Develop sections in [[FlightGear Git on Windows]].

# Create a directory on your computer where you'll be storing the data.
# Change into that folder.
# Do the following steps to extract the bundle and bring the repository up to date:
#:<code>git clone fgdata.bundle fgdata</code>
#:<code>cd fgdata</code>
#:<code>git checkout -b master-tmp</code>
#:<code>for N in 01 02 03 04 05 06 07 08 09 10 11; do git pull ../fgdata-update-0$N.bundle master; done</code>
#:<code>git remote rm origin</code>
#:<code><nowiki>git remote add origin git://mapserver.flightgear.org/fgdata</nowiki></code>
#:<code>git fetch origin</code>
#:<code>git branch --track master origin/master</code>
#:<code>git checkout master</code>
#:<code>git branch -D master-tmp</code>

You should be suspicious if based on the printed progress during the <code>git fetch origin</code> phase you estimate the data download during the fetch will exceed 1GB (assuming the bundle is not terribly outdated).

=== Authentication ===
In order to publish edits on Gitorious, you need to generate a secret key so you can be correctly identified.

# Navigate to your newly created fgdata directory and run:
#: <code>ssh-keygen</code>
# Enter the name of the file in which you prefer to save the key and press Enter.
# Enter your password/passphrase and press Enter. You'll have to do this twice.
# Your key is now being generated. Open the .pub file with an editor and copy the content.
# Visit your dashboard at Gitorious and navigate to "Manage SSH keys".
# Click the "Add SSH key" button and paste the content of the .pub file. Follow the instructions on the screen.
# Now run the following, again in your fgdata directory, with ''<url>'' as the line that you get by clicking SSH on your fgdata clone page at Gitorious (something like ''git@gitorious.org:~your/fg/yours-fgdata.git''):
#: <code>git remote set-url origin <url></code>

=== Obtaining the simulator ===
In order to test your work, you'll need the FlightGear version that matches the data. Since FlightGear is under constant development, data from Git does not work with previous releases. Fortunately obtaining the latest development version of the simulator is fairly straightforward for most operating systems.

* '''Mac:''' Download [http://flightgear.simpits.org:8080/job/FlightGear-mac/ the .dmg]
* '''Windows:''' Download the [http://flightgear.simpits.org:8080/job/Win32-installer-Cmake 32-bits] or [http://flightgear.simpits.org:8080/job/Win64-installer-Cmake 64-bits] installer and follow its instructions. Let it install the binary into a clean directory.

Point [[$FG_ROOT]] to your freshly obtained fgdata directory. When using [[FlightGear Launch Control|the launcher]], this can be done on the first page, previous from the aircraft selection.

== Making edits ==
It is recommended to split your new fgdata clone into separate local branches for your work. For instance, if you're working on the Boeing 747-400 and the aircraft reflection shader, you might create 2 branches named "747-400" and "reflect-shader". To do this, run the following commands:
:<code>git checkout master</code>
:<code>git checkout -b <branch name></code>
Then you can make your changes to the new local branch(es), which will make merge requests easier for both yourself and committers. To switch in between branches, simply use
:<code>git checkout <branch name></code>

== Publishing edits ==
To push local updates to your fgdata clone on Gitorious, perform the following steps:
# Switch to the branch that contains your edits:
#:<code>git checkout <branch name></code>
# List all the changed files:
#:<code>git status -- .</code>
# Now it's time to commit the changed files.
#* If you want to commit all changed files, run the following and type your commit message.
#*: <code>git commit -a</code>
#* If you only want to commit a selection of files, run the following:
#*: <code>git add <path/to/file></code> (for single files)
#*: <code>git add --all <path/to/folder></code> (to add all files within a certain folder)
#*: <code>git rm <path/to/file></code> (to remove files that you've removed)
#: Followed by
#:: <code>git commit -m "<commit message>"</code>
# Check if everything went fine, by loading Gitk:
#: <code>gitk</code>
# Finally, push the commit to your fgdata clone Gitorious with the following command. Replace <code>YourUID</code> with your Gitorious account:
#: <code>git push git@gitorious.org:~YourUID/fg/YourUIDs-fgdata.git</code>

== Requesting edits to be merged ==
[[File:Create merge request at Gitorious.png|thumb|270px|Creating a merge request at Gitorious.]]
# Click the "Request merge" button on your fgdata clone page. Loading the next page can take a while, as it will list all commits of the past years!
# Once again write a short summary (could be the same as used with git commit), but this time, also write an explanation of your merge request (what does it do?). Make sure you set the target repository to fgdata, target branch to master and source branch to the local branch with your updates.
# Tick the box in front of your commit and click the "Create merge request" button.
# Everyone can see the pending request, but in order to make sure that your request gets looked at, you may contact a contributor. You can find a list of people on the right side of the [https://gitorious.org/fg/fgdata repository page].

Creating merge requests using this method literally means merging an entire branch into fgdata; this may not be desirable for some situations, such as small changes that only require one little commit. There's a neat method to only push certain commits to a merge request discussed by Anders Gidenstam [http://forum.flightgear.org/viewtopic.php?f=4&t=10392&start=45#p115747 on the FlightGear Forums].

[[Category:Git]]

Talk:TerraGear scenery build server

2014-07-10T01:13:37Z

Flyhigh: /* Terragear Build Issues */ new section

== Server & Hosting (D-YETI) ==
By the way I personally would give some computing time and IO /Diskspace, at the server listed below, too, because I hope much more pople will benefit from it than running it for me alone. Since Terragear is not so easy to install and even with the gui doesn't always give the result I was expecting.

* Intel® Core™ i5-4570 CPU @ 3.20GHz × 4
* 32GB RAM
* SSD + RAID
* but rather slow Internet connection. (600kbit/s dn / 128kbit/s up)

== Potential TerraGear Issues (psadro_gm) ==
An issue you will may hit is that some terragear tools don't behave very well when run at the same time (genapt and ogrdecode, in particular). this may work with two separate work directories, but I have not tried it. If using the same work directory, You can hit some directory / file creation collisions. To recitify these, I added a Boost global mutex so one can write at a time. With multiple users, this may become a bottleneck.

== Packaging (saiarcot895 ) ==
'''Hooray:'''Obviously, one major part of this would involve installing/packaging SimGear and TerraGear as *.deb files.
This would greatly simplify the installation - we do have several instructions related to this, and even a script - so we could change the script to build SG/TG and then package things afterwards.

Ideally, SimGear would be built in "headless" mode - i.e. minus all the OSG dependencies, no sound etc required: http://wiki.flightgear.org/Building_using_CMake#SimGear_Build_Options

So we would first of all end up with something like "libsimgear-headless-dev" which could be used to build TerraGear.
The next step would be creating a package for TerraGear itself that depends on SimGear-headless-dev

Once these two steps are completed, setting up TerraGear on Linux should become much more straightforward.
And we could use these packages to set up a TerraGear build server.

All this will be based on TurnKeyLinux, which is a debian/wheezy based distro, intended for "remastering" - so that new virtual appliances can be easily created, and exported - so that others can install an ISO file to get a working TG setup.

For now, I simply built SG headless (libsimgearcore) and installed it system-wide and it's working properly.

But obviously it would be better to come up with packages for both, SG and TG (64bit).
Which would be useful for all debian/ubuntu users, not just this particular effort.

Also, we would need to publish those packages, so that people only need to add the repo to download updates automatically.

Overall, this would help greatly simplify TG deployment obviously, no matter if it's about having a build server or not.

Looking at SG/FG, the best option seems to be to use cmake's cpack support to create packages: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

:'''saiarcot895''': I think I can help here.

:Part of the work may have been already done. We are distributing simgear in two packages (since there are two libraries): libsimgearcore and libsimgearscene. libsimgearcore doesn't have any graphical dependencies; it only depends on libc6. libexpat, libgcc1, libstdc++6, and zlib1g. The only drawback here is that the -dev package includes headers for both libraries, which would require both libraries be installed. Would libsimgearcore be equivalent to the library produced by SIMGEAR_HEADLESS?

:'''saiarcot895''': I just uploaded the terragear package to my [https://launchpad.net/~saiarcot895/+archive/flightgear-edge flightgear-edge PPA]. It should be built and available in about 20-30 minutes for users of Ubuntu Precise, Quantal, and Trusty, but ''not'' Saucy (someone decided to place the Boost libraries on Saucy at a weird place, and so I get to find a fix to that). If you use Debian, I ''think'' you can download the debs for the Quantal version and use that.

:: '''Hooray:''' There seems to be a dependency issue regarding libtiff according to [https://launchpadlibrarian.net/166371092/buildlog_ubuntu-precise-amd64.terragear_2.1.0~1196%2Bgitf089559-0ubuntu1~ppa1~precise1_MANUALDEPWAIT.txt.gz] ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:15, 15 February 2014 (UTC)

:::'''saiarcot895''': Already on it. I got another dependency issue with libgdal (apparently, they changed the development package name right after Precise). [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:10, 15 February 2014 (UTC)

:::: '''Hooray:''' Would it be a lot of work to set up launchpad such that it also provides a debian wheezy (64bit) package ? That's what I am currently using - otherwise, I'd need to change some things here - so it depends on the amount of work involved obviously. Thanks for looking into it! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 04:09, 16 February 2014 (UTC)

::::: '''saiarcot895''': Sorry for the delay. The Launchpad PPAs are Ubuntu-only, but I can easily create deb files for Wheezy. It's just a matter of publishing it somewhere. Also, I might have a patch to send regarding having an explicit #include <std::string> line in a file. Something is different in Precise that an explicit #include is necessary. Also, I finally fixed the annoying bug in Saucy; it was actually a bug in CGAL having the incorrect Boost location in its config file. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 16:14, 8 March 2014 (UTC)

::::: '''saiarcot895''': I've built simgear and terragear for the unstable/sid repo, and the packages are available at http://128.61.105.135/apt. To get it down to wheezy, however, I'll have to bump up (at least) OpenSceneGraph from unstable because wheezy still has 3.0. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 15:30, 9 March 2014 (UTC)

: '''Hooray:''' Sorry for not getting back to this earlier, thanks for the updates and all your work here. You raised a few good points - I am wondering if we can avoid the OSG issue in this particular instance for now, because we really only require the "headless" part of SimGear for TG, i.e. OSG should not even be required normally, right ? Otherwise, you're right that it would make sense to also provide deb packages for wheezy. But just for TG, I think, we don't need to touch any OSG related stuff ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:13, 9 March 2014 (UTC)

:: '''saiarcot895''': You're right, I forgot about that. I've built simgear (in headless mode) for unstable and will build it for testing (jessie) and stable (wheezy), and will build terragear for all three releases once simgear is done. This should be done in a few hours. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:36, 10 March 2014 (UTC)

:: '''saiarcot895''': Simgear for all releases is done, and Terragear for unstable is done. However, Terragear on testing failed with an error in a boost include saying uintptr_t wasn't found...which doesn't make sense to me since boost is from the main Debian archives. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:28, 11 March 2014 (UTC)

::: '''Hooray:''' Thank you, I will be testing this shortly and have forwarded instructions to D-YETI who offered to provide hosting for this.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 17:32, 11 March 2014 (UTC)

Ok, I added your URL to apt/source.lst on Deb Wheezy (64 bit) and ran apt-get update, when doing "apt-cache search" (simgear/terragear) your repo shows up correctly with the SG packages:
* core
* dev
* dbg

And installation worked without problems, however terragear does not currently show up as a separate package yet, and also isn't listed [http://128.61.105.135/apt/dists/wheezy/main/binary-amd64/Packages in the files on the server] apparently ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:02, 11 March 2014 (UTC)

: '''saiarcot895''': Refresh it and check it now. It should be there. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 20:37, 11 March 2014 (UTC)

::: '''Hooray:''' Confirmed, this works now properly - just took 3 seconds to install TG here now on a fresh system, surprisingly not even SG was required (static build?) Very good job indeed! Now, we'll need to document this and spread the good news (article/newsletter). I'll also try to get in touch with D-YETI to see if he still can contribute hosting, which would also be a good way to host the actual TG packages. I guess we could ask Curt to set up a subdomain like packages.flightgear.org to host deb/ppa packages there for i386/amd64. Did you prepare those packages manually, or where you able to use cmake's cpack support for this ? I am asking because I guess it would be a good idea to strive towards using cmake/cpack for this, so that package creation can be automatically supported for SG/FG/TG for each upcoming release, without involving manual work - possibly by running things via the build server (nightly snapshots/prereleases).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:58, 11 March 2014 (UTC)

:::: '''saiarcot895''': Strange; it has a dependency on libsimgearcore3.1.0, and it's not a static build. Ah well; if it works, you're fine. I did a mix of both manual stuff and scripts, but updates can be fully scripted (which is what I'm doing for my edge PPA). I used scripts from the debhelper package to generate the source package (I think you can get the source package and the debian folder using "sudo apt-get source terragear"), and then used sbuild to recreate a Debian Wheezy chroot and build it in that chroot. It looks like CPack asks for much of the same things as the debian/control file. Also, I'm not sure if CPack generates the .dsc and .changes file, which is necessary for publishing it to a repo. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:33, 11 March 2014 (UTC)

'''saiarcot895''': I'm getting a build failure with TerraGear git commit 25294ee and simgear git commit 1948198.

<code>
<blockquote>
/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1144:9: error: 'class SGBinObject' has no member named 'set_pts_v'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1145:9: error: 'class SGBinObject' has no member named 'set_pts_n'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1146:9: error: 'class SGBinObject' has no member named 'set_pt_materials'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1147:9: error: 'class SGBinObject' has no member named 'set_tris_v'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1148:9: error: 'class SGBinObject' has no member named 'set_tris_n'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1149:9: error: 'class SGBinObject' has no member named 'set_tris_tc'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1150:9: error: 'class SGBinObject' has no member named 'set_tri_materials'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1151:9: error: 'class SGBinObject' has no member named 'set_strips_v'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1152:9: error: 'class SGBinObject' has no member named 'set_strips_n'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1153:9: error: 'class SGBinObject' has no member named 'set_strips_tc'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1154:9: error: 'class SGBinObject' has no member named 'set_strip_materials'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1155:9: error: 'class SGBinObject' has no member named 'set_fans_v'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1156:9: error: 'class SGBinObject' has no member named 'set_fans_n'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1157:9: error: 'class SGBinObject' has no member named 'set_fans_tc'

/build/buildd/terragear-2.1.0~1200+git25294ee/src/Airports/GenAirports850/airport.cxx:1158:9: error: 'class SGBinObject' has no member named 'set_fan_materials'
</blockquote>
</code>

Does someone need to update the code here? (cause of error is SG commit 5b2b420) [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 01:27, 8 April 2014 (UTC)

Please use git branch scenery/ws2.0 for building packages - it is the current stable branch. We are working on new features that need some simgear coordination in master. This work is temporarily stalled for Simgear feature freeze. --[[User:Psadro gm|Psadro gm]] ([[User talk:Psadro gm|talk]]) 13:03, 7 July 2014 (UTC)

Thank you for the update, Psadro gm. Currently, I'm bringing up-to-date both simgear and terragear. The latest simgear is in sid and jessie (testing), and terragear will be going in soon. I'll need to build a few additional packages in sid (stable), since OpenSceneGraph 3.2 isn't in sid. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 02:20, 9 July 2014 (UTC)

:: Just keep in mind: as per our discussion above, TG/SG can be built in "headless" mode and shouldn't require OSG necessarily. Thanks again for your efforts here, really appreciated ! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 02:55, 9 July 2014 (UTC)

== TerraGear & TerraGear GUI (reeed) ==
this damned build server idea doesn't want to go away!

very quickly now, to get me up to speed:
* is a hosting server available for our use right away? or who are the probable candidate(s)?
* who maintains the latest, compileable and functional TerraGear?
* Is the above TG packaged with Gijs' GUI? If not, which one is packaged?

== TurnkeyLinux (Hooray) ==
* http://www.turnkeylinux.org/blog/introducing-tkldev
* http://www.turnkeylinux.org/forum/support/20120507/how-create-customized-appliance
* https://github.com/turnkeylinux-apps/tkldev/tree/master/docs

== WebService / UI (F-JJTH, Gijs, Hooray, reeed ) ==

{{Progressbar|40}} (proof-of-concept by F-JJTH)

'''Gijs:'''It'd be nicer/better to have a web interface. That'll allow you to keep the interface and backend in sync (without asking people to recompile/redownload the GUI om each change), save people from downloading yet another tool and make it work/look the same on all systems.

: '''Hooray:''' As I mentioned on the forum, I am not at all opposed to having a webservice, I just consider it much more straightforward to modify [[TerraGear GUI]] for now. if there's anybody interested in working on a web interface that would obviously be great, but short of that, I would simply modify TerraGear GUI to support two modes local (default) and remote (build server) over SSH. I already looked at the code briefly and the main issue is the amount of Qt code that runs locally, i.e. to download stuff for example - if that could be moved out into external programs, preferably part of TerraGear itself, then it would be trivial to support both, local AND remote TG installations. Currently, there's just too much stuff directly done, without calling external tools - so that would need to be factored out.
: Overall, the TerraGear GUI is not such a complex code base, so I am not sure if keeping the frontend/backends in sync is such a huge issue ?? I mean, people ALREADY need to have a matching TG/TGGUI versions after all ...
: I am certainly not going to stop anybody from coming up with a webservice - it's just something that I am probably not going to work on anytime soon - while modifying TGGUI accordingly would just take a few hours and involve well-understood steps.
: So I wasn't thinking of forking TGGUI, but more about extending it to support local AND remote installations - selected/configured during startup.

: Obviously you are much more familiar with the code in question here - but based on what I've seen, it would not be such a difficult undertaking to turn TGGUI into a "remote control" for a TG build server setup.

: If frontend changes are such an issue, I would actually suggest to get rid of the hardcoded GUI and use Qt's scripting support for those *.ui files instead - that would allow you to automatically download QtScript while booting.

: Finally, coming up with a working web service is in my opinion more difficult than using SSH to teach TGGUI to run a handful of commands remotely and fetch the results via SFTP - so yeah, I am kinda lazy here

== Standalone GUI (via SSH) ==

If the consensus should end up being not to use [[TerraGear GUI]], the most straightforward option for coming up with a simple GUI would be Python using SSH and GUI bindings:

* http://docs.fabfile.org/en/1.4.2/index.html
* http://hackerific.net/2009/02/06/paramiko-scripting-ssh-with-python/
* http://jessenoller.com/2009/02/05/ssh-programming-with-paramiko-completely-different/
* https://github.com/paramiko/paramiko
* http://www.pythonforbeginners.com/code-snippets-source-code/ssh-connection-with-python/
* http://sourceforge.net/projects/pexpect/

== Terragear Build Issues ==

(I decided to create a new section instead of continuing in an off-topic section)

I found another build error, although this might be due to changes in upstream. Here's the build log:

<pre>cd "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Prep/DemChop" && /usr/bin/cmake -E cmake_link_script CMakeFiles/hgtchop.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -frounding-math -Wall -D_REENTRANT -DNO_OPENSCENEGRAPH_INTERFACE -O3 -DNDEBUG -Wl,-z,relro -Wl,--as-needed CMakeFiles/hgtchop.dir/hgtchop.cxx.o -o hgtchop -rdynamic -lmpfr -lgmp -lCGAL_Core -lCGAL -lboost_thread -lboost_system -lpthread ../../Lib/HGT/libHGT.a -lz -lSimGearCore -lpthread -lz -lrt -lmpfr -lgmp -lCGAL_Core -lCGAL -lboost_thread -lboost_system -lpthread -lSimGearCore -lpthread -lrt
In file included from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_contour.hxx:12:0,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_polygon.hxx:64,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_chopper.hxx:3,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_chopper.cxx:9:
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx: In constructor 'SGGeodIndex::SGGeodIndex(SGGeod)':
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx:44:27: warning: large integer implicitly truncated to unsigned type [-Woverflow]
FNV_prime = 1099511628211ULL;
^
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx:45:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
offset_basis = 14695981039346656037ULL;
^
make[3]: Leaving directory '/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build'
/usr/bin/cmake -E cmake_progress_report "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/CMakeFiles" 33
[ 25%] Built target hgtchop
/usr/bin/cmake -E cmake_progress_report "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/CMakeFiles" 46
[ 26%] Building CXX object src/Lib/terragear/CMakeFiles/terragear.dir/tg_contour.cxx.o
cd "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Lib/terragear" && /usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_MPFR -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -frounding-math -Wall -D_REENTRANT -DNO_OPENSCENEGRAPH_INTERFACE -O3 -DNDEBUG -isystem /usr/include/i386-linux-gnu -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Include" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib" -I/usr/include/gdal -o CMakeFiles/terragear.dir/tg_contour.cxx.o -c "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_contour.cxx"
/usr/bin/cmake -E cmake_progress_report "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/CMakeFiles" 47
[ 28%] Building CXX object src/Lib/terragear/CMakeFiles/terragear.dir/tg_misc.cxx.o
cd "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Lib/terragear" && /usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_MPFR -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -frounding-math -Wall -D_REENTRANT -DNO_OPENSCENEGRAPH_INTERFACE -O3 -DNDEBUG -isystem /usr/include/i386-linux-gnu -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Include" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib" -I/usr/include/gdal -o CMakeFiles/terragear.dir/tg_misc.cxx.o -c "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_misc.cxx"
/usr/bin/cmake -E cmake_progress_report "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/CMakeFiles" 48
[ 29%] Building CXX object src/Lib/terragear/CMakeFiles/terragear.dir/tg_nodes.cxx.o
cd "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Lib/terragear" && /usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_MPFR -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -frounding-math -Wall -D_REENTRANT -DNO_OPENSCENEGRAPH_INTERFACE -O3 -DNDEBUG -isystem /usr/include/i386-linux-gnu -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/build/src/Include" -I"/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib" -I/usr/include/gdal -o CMakeFiles/terragear.dir/tg_nodes.cxx.o -c "/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_nodes.cxx"
In file included from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_contour.hxx:12:0,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_polygon.hxx:64,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_accumulator.hxx:4,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_contour.cxx:6:
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx: In constructor 'SGGeodIndex::SGGeodIndex(SGGeod)':
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx:44:27: warning: large integer implicitly truncated to unsigned type [-Woverflow]
FNV_prime = 1099511628211ULL;
^
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_unique_geod.hxx:45:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
offset_basis = 14695981039346656037ULL;
^
In file included from /usr/include/CGAL/assertions.h:36:0,
from /usr/include/CGAL/basic.h:42,
from /usr/include/CGAL/Cartesian/Cartesian_base.h:28,
from /usr/include/CGAL/Simple_cartesian.h:28,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_nodes.hxx:10,
from /«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_nodes.cxx:2:
/usr/include/CGAL/Search_traits_adapter.h: In instantiation of 'class CGAL::Search_traits_adapter<boost::tuples::tuple<CGAL::Point_2<CGAL::Simple_cartesian<double> >, double>, My_point_property_map, CGAL::Search_traits_2<CGAL::Simple_cartesian<double> > >':
/«BUILDDIR»/terragear-2.1.0~1202+git47db776/src/Lib/terragear/tg_nodes.hxx:35:29: required from here
/usr/include/CGAL/Search_traits_adapter.h:75:3: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'
BOOST_STATIC_ASSERT( ( boost::is_same< boost::lvalue_property_map_tag,</pre>

The version of CGAL is 4.4-1+b1, and the version of Boost is 1.55.0+dfsg-2. This actually might be an incompatibility in CGAL with Boost.

Talk:TerraGear scenery build server

2014-07-09T02:20:00Z

Flyhigh: /* Packaging (saiarcot895 ) */

Building FlightGear - Linux

2014-05-14T17:06:03Z

Flyhigh: Ubuntu PPA

{{Main article|Building Flightgear}}

This section describes how to build [[FlightGear]] on Linux system.

Compiling FlightGear is not a task for novice users. Thus, if you're a beginner (we all were once) on a platform which binaries are available for, we recommend postponing this task and just starting with the binary distribution to get you flying.

openSUSE also provides binary packages of the latest development version, which are continuously updated.
Follow [http://software.opensuse.org/download.html?lang=en&project=games:FlightGear:Unstable&package=fgrun this link] to select your openSUSE version and install, or manually add ''games:FlightGear:Unstable'' to your ''YaST Software Repositories''.

For Ubuntu, there is a PPA that provides the latest development version of FlightGear and SimGear and a recent version of FlightGear data. See [https://launchpad.net/~saiarcot895/+archive/flightgear-edge this page] for more info. To add the PPA, run <tt>sudo apt-add-repository ppa:saiarcot895/flightgear-edge</tt>.

Or if you develop on Ubuntu or Debian, consider trying the script described in [[Scripted Compilation on Linux Debian/Ubuntu]].

== Distro-specific instructions ==
=== Debian/Ubuntu ===
* You can use the [[Scripted Compilation on Linux Debian/Ubuntu]] script to have Flightgear compiled in one shot under both Ubuntu and Debian systems.
* Debian users who prefer to build it without script may look at [[Building Flightgear - Debian]].
* Hints for [[Ubuntu]] users.

=== Gentoo ===
* Gentoo users can also use overlays to build FlightGear without much hassle: [[Building Flightgear - Gentoo]].

== Requirements ==
Before you can compile FlightGear, you need to have the following installed on your computer:

'''C++ compiler'''

These are: c++, cpp, gcc, g++ found under the <code>/usr/bin</code> directory. You will also need to have the tools '''autoconf''' and '''automake1.9''' installed.

'''GIT'''

See [[FlightGear and Git]].

'''[[OpenGL]] support'''

More specifically, your system needs the support for hardware accelerated graphics. You can check for this by running the following in a [[command line]]:

<syntaxhighlight lang="bash">
$ glxinfo | grep direct
</syntaxhighlight>

Note: To run the above command, you need to have the tool '''mesa-utils''' installed.

You should then see:

direct rendering: Yes

This means you are good to go as far as OpenGL support is concerned.

If you see:

direct rendering: No

Don't panic yet. This may just mean some required libraries for hardware accelerated graphic are missing. Go ahead and try installing '''plib 1.8.5''' and its dependencies first. If you still get the above message, then you will need to do some googling and troubleshoot yourself.

== Dependencies ==

FlightGear is dependent on quite a few number of libraries. You do not need to compile all of them yourself, but you will at least need to have their development version installed. For example, the development version for package <tt>plib1.8.5</tt> is <tt>plib1.8.5</tt>'''-dev'''.

The dependency is summarized in the following tree. Please note that each library has its own dependencies, and most of these are not shown here.

* <tt>FlightGear</tt>
** [http://kcat.strangesoft.net/openal.html <tt>OpenAL</tt>]
** <tt>SimGear</tt>
*** [http://plib.sourceforge.net/ <tt>PLIB</tt>]. Since March 2008, you will need version 1.8.5 - your distro probably supplies 1.8.4 still.
**** For versions pre March 2008: (Free)<tt>GLUT</tt> or <tt>SDL</tt> (We recommend the use of <tt>SDL</tt> over <tt>Free/GLUT</tt>, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16153.html however since March 2008, <tt>FreeGLUT</tt> as well as <tt>SDL</tt> are both considered deprecated], please only use <code>--enable-osgviewer</code> during configuration instead)
*** <tt>[[OpenSceneGraph]]</tt> (check link for compatible versions)
*** You also need the development files for several basic libraries to build the software, among them the following (the package names are for Debian and derivatives(?)):
**** <tt>libfreetype6-dev</tt>
**** <tt>libjpeg62-dev</tt>
**** <tt>libungif4-dev</tt>
**** <tt>libtiff4-dev</tt>
**** <tt>libpng12-dev</tt>
**** <tt>libxmu-dev</tt>
**** <tt>libxi-dev</tt>
**** <tt>zlib1g-dev</tt>
**** <tt>libglut3-dev</tt>

If you attack the above dependencies in the order listed below, you should be good:

# <tt>glut</tt> Most distributions include glut packages, although you may have to hunt for them. Make sure you install both the <tt>glut</tt> and <tt>glut-devel</tt> packages, otherwise FlightGear may be able to compile but won't run correctly.
# <tt>zlib</tt> Most distributions install the basic <tt>zlib</tt> libraries by default, but not the development portions. If you don't have <tt>zlib.h</tt>, you probably need to install the <tt>zlib-devel</tt> package for your distribution.
# <tt>plib</tt> Portability libraries and scene graph.
# <tt>[[OpenSceneGraph]]</tt>
# <tt>simgear</tt> Simulation support libraries. If you are building FlightGear from Git, you need the Git version of SimGear. If you have strange build errors, one of the first things to check is that you have an up-to-date version of SimGear built and installed.

== Compiling ==
Assuming you are root, do:

<syntaxhighlight lang="bash">
# cd /usr/local/src
</syntaxhighlight>

'''Note:''' When tracking a fast changing software like FlightGear/Git it is highly advisable to install it in a separate directory. That way one can also easily build and reinstall without being root, which greatly reduces the risk of messing up one's system.
To install in a directory of your choice add the <tt>--prefix</tt> argument to configure. E.g. <tt>./configure --prefix=$HOME/FlightGear</tt>. I would recommend installing all of OSG, plib, SimGear and FlightGear with the same prefix.

=== Getting and compiling SimGear ===

'''Step 1:'''

Clone the SimGear git repository and set it up to track the 'next' branch.

<syntaxhighlight lang="bash">
$ git clone git://gitorious.org/fg/simgear.git
</syntaxhighlight>

or if the git port is firewalled on you network, use the http transport

<syntaxhighlight lang="bash">
$ git clone http://gitorious.org/fg/simgear.git
</syntaxhighlight>

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with <code>git pull</code>.

'''Step 2:'''

The source code will be downloaded into a directory called '''simgear'''.

Next, go into the directory and make preparations for the compilation:

<syntaxhighlight lang="bash">
$ cd simgear
$ cmake .
</syntaxhighlight>

'''Note''' that if you don't want to install <tt>simgear</tt> globally on the system but in a specific directory, you can do so by adding <code>-DCMAKE_INSTALL_PREFIX==/path/to/your/fgInstallation</code> to the <code>cmake</code> command

'''Step 3:'''

Compile and install SimGear by doing:

<syntaxhighlight lang="bash">
$ make; make install
</syntaxhighlight>

''Note:'' with <tt>gcc</tt> 4.2 or later,on some platforms, you can get compiling errors about <tt>alc.h</tt> like:

'<anonymous>' has incomplete type
take a look at http://bugs.gentoo.org/166723

=== Getting and compiling FlightGear ===

'''Step 1:'''

Clone the FlightGear git repository and set it up to track the 'next' branch.

<syntaxhighlight lang="bash">
$ git clone git://gitorious.org/fg/flightgear.git
</syntaxhighlight>

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

Next, go into the folder and make preparations for the compilation:

<syntaxhighlight lang="bash">
$ cd flightgear
$ ./autogen.sh
$ ./configure
</syntaxhighlight>

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command.
If you didn't install OSG globally or in the same prefix as SimGear and FlightGear, you have to pass the OSG directory to the configure-command like this:

<syntaxhighlight lang="bash">
$ ./configure --prefix=/path/to/fgInstallation --with-osg=/path/to/osg/installation --enable-osgviewer
</syntaxhighlight>

In this case you have to tell your system where to find the OSG libraries before you can run flightgear:

<syntaxhighlight lang="bash">
$ export LD_LIBRARY_PATH=/path/to/osgInstallation/lib:$LD_LIBRARY_PATH
</syntaxhighlight>

'''Step 3:'''

Now you can compile and install Flightgear by:

<syntaxhighlight lang="bash">
$ make; make install
</syntaxhighlight>

'''Step 4:'''

Clone the data directory:

<syntaxhighlight lang="bash">
$ git clone git://gitorious.org/fg/fgdata.git
</syntaxhighlight>

The data directory is large (almost 2.5GB) so it will take considerable time to download.
There mirror of fgdata that might be faster to download from:

<syntaxhighlight lang="bash">
$ git clone git://mapserver.flightgear.org/fgdata
</syntaxhighlight>

The mirror is synchronized with the master so either will do.

And install it in (or as) /usr/local/share/FlightGear

<syntaxhighlight lang="bash">
$ mv fgdata /usr/local/share/flightgear
</syntaxhighlight>

== External links ==
=== Instructions ===
* [[MSYS]]
* [[MinGW/cross-compiler]]
* [[CodeBlocks IDE]]
* [[OpenSUSE 10.1 10.2]]
* [http://www.geoffmclane.com/fg/fgmsvc7.htm MSVC7 *.Net]
* [http://www.oflebbe.de/oflebbe/FlightGear/index.html MSVC8 aka Visual 2005]
* [http://macflightgear.sourceforge.net/home/documents/ Mac OS X]
== Important note for GIT users ==
As of latest development in GIT, only cmake is now required for building both SimGear and FlightGear. So if you build GIT (for what any reason) please don't try to use autogen.sh as it is removed from repository.

For detailed instructions, see page [[Building_using_CMake|Building using cmake]].

{{Building}}

[[fr:Compiler FlightGear sous GNU/Linux]]

Talk:TerraGear scenery build server

2014-04-08T01:30:36Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-04-08T01:27:28Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-11T21:33:58Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-11T20:37:40Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-11T00:28:40Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-10T21:37:43Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-10T21:36:02Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-09T15:30:47Z

Flyhigh: /* Packaging (saiarcot895 ) */

Talk:TerraGear scenery build server

2014-03-08T16:14:57Z

Flyhigh: /* Packaging (saiarcot895 ) */

Howto:Install Flightgear from a PPA

2014-02-20T20:35:00Z

Flyhigh: Tense correction

Currently, in the official Ubuntu repositories, Ubuntu 12.04 (Precise) has [[FlightGear]] 2.4.0, Ubuntu 12.10 (Quantal) and Ubuntu 13.04 (Raring) have FlightGear 2.6.0, and Ubuntu 13.10 (Saucy) has FlightGear 2.10.0. The upcoming Ubuntu 14.04 (Trusty) will have FlightGear 3.0.0. Since the older Ubuntu versions don't have a simple installation method, I'm providing a PPA from which you can download FlightGear and some aircraft from. Here is a list of FlightGear-related PPAs:

* Stable: [https://launchpad.net/~saiarcot895/+archive/flightgear FlightGear]
* Prerelease: [https://launchpad.net/~saiarcot895/+archive/flightgear-prerel FlightGear Prerelease] (only active when there is a new release coming up)
* Daily(ish): [https://launchpad.net/~saiarcot895/+archive/flightgear-edge FlightGear Daily]

== Installing FlightGear ==

'''NOTE''': The menu bar may be initially hidden. You can restore this using the F10 key.

=== Upgrading ===
You can just update and upgrade. Note that, after the upgrade, you will have the packages libsimgearcore2.12.0 and libsimgearscene2.12.0. You can safely remove these two libraries after the upgrade.

sudo apt-get update
sudo apt-get dist-upgrade

=== Fresh install ===
If you are doing a fresh FlightGear install (you haven't installed FlightGear from this PPA or the prerelease/daily PPAs) and you haven't added this PPA, you'll need to do the commands below:

sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get install flightgear

== Installing additional aircraft ==
I am providing some additional aircraft that you can download straight from the PPA. To install them, run the following command:

sudo apt-get install flightgear-data-aircrafts-''aircraftname''

Replace ''aircraftname'' with one of the following:

{| class="wikitable"
! ''aircraftname'' !! Aircraft
|-
| a10
| [[Fairchild Republic A-10 Thunderbolt II]]
|-
| a380
| [[Airbus A380]]
|-
| b747-400
| [[Boeing 747-400]]
|-
| dc3
| [[Douglas DC-3]]
|-
| dr400-dauphin
| [[Robin DR400 Dauphin]]
|-
| ec130
| [[Eurocopter EC130 B4]]
|-
| p51d
| [[North American P-51 Mustang|P-51 Mustang]]
|-
| seafire
| [[Supermarine Seafire]]
|-
| spitfire
| [[Supermarine Spitfire]]
|-
| tu154b
| [[Tupolev Tu-154B]]
|}

[[Category:Howto|Install Flightgear from a PPA]]

Howto:Install Flightgear from a PPA

2014-02-20T20:34:20Z

Flyhigh: Updated for 3.0.0

Currently, in the official Ubuntu repositories, Ubuntu 12.04 (Precise) has [[FlightGear]] 2.4.0, Ubuntu 12.10 (Quantal) and Ubuntu 13.04 (Raring) have FlightGear 2.6.0, and Ubuntu 13.10 (Saucy) has FlightGear 2.10.0. The upcoming Ubuntu 14.04 (Trusty) had FlightGear 3.0.0. Since the older Ubuntu versions don't have a simple installation method, I'm providing a PPA from which you can download FlightGear and some aircraft from. Here is a list of FlightGear-related PPAs:

* Stable: [https://launchpad.net/~saiarcot895/+archive/flightgear FlightGear]
* Prerelease: [https://launchpad.net/~saiarcot895/+archive/flightgear-prerel FlightGear Prerelease] (only active when there is a new release coming up)
* Daily(ish): [https://launchpad.net/~saiarcot895/+archive/flightgear-edge FlightGear Daily]

== Installing FlightGear ==

'''NOTE''': The menu bar may be initially hidden. You can restore this using the F10 key.

=== Upgrading ===
You can just update and upgrade. Note that, after the upgrade, you will have the packages libsimgearcore2.12.0 and libsimgearscene2.12.0. You can safely remove these two libraries after the upgrade.

sudo apt-get update
sudo apt-get dist-upgrade

=== Fresh install ===
If you are doing a fresh FlightGear install (you haven't installed FlightGear from this PPA or the prerelease/daily PPAs) and you haven't added this PPA, you'll need to do the commands below:

sudo add-apt-repository ppa:saiarcot895/flightgear
sudo apt-get update
sudo apt-get install flightgear

== Installing additional aircraft ==
I am providing some additional aircraft that you can download straight from the PPA. To install them, run the following command:

sudo apt-get install flightgear-data-aircrafts-''aircraftname''

Replace ''aircraftname'' with one of the following:

{| class="wikitable"
! ''aircraftname'' !! Aircraft
|-
| a10
| [[Fairchild Republic A-10 Thunderbolt II]]
|-
| a380
| [[Airbus A380]]
|-
| b747-400
| [[Boeing 747-400]]
|-
| dc3
| [[Douglas DC-3]]
|-
| dr400-dauphin
| [[Robin DR400 Dauphin]]
|-
| ec130
| [[Eurocopter EC130 B4]]
|-
| p51d
| [[North American P-51 Mustang|P-51 Mustang]]
|-
| seafire
| [[Supermarine Seafire]]
|-
| spitfire
| [[Supermarine Spitfire]]
|-
| tu154b
| [[Tupolev Tu-154B]]
|}

[[Category:Howto|Install Flightgear from a PPA]]

Release plan

2014-02-17T23:34:02Z

Flyhigh: /* Detailed time schedule and checklist */ Fix typo in syntax

{{GitStatus}}

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. In particular, improvements should be based on [[Release plan/Lessons learned]] from past releases. Please discuss this concept at the mailing-list.

== General release concept ==
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

{{cquote|As a clarification: We do not enter a code freeze but a feature freeze. Code changes are welcome after December 17th as long as it is guaranteed (not just "unlikely") that they do not introduce any side effects and become a release blocker. It is the sole responsibility of the commiter to decide if that is the case or not. Every new feature that didn't make it into the respository by the deadline may probably easily wait for another four weeks to get commited. Remember: most aircraft are not affected by the feature freeze and aircraft developers quickly adopt and use new features as they become available<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html|title=<nowiki>[Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki>|author=Torsten Dreyer|date=16 November 2012}}</ref>|Torsten Dreyer}}

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear, FGRun and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

== Version numbers ==
FlightGear version numbers consist of three digits, seperated by dots:
* '''Major''' (2.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).
* '''Minor''' (2.4.1): has two applications:
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release was 2.8.0, the current development stream is 2.9.0.
* '''Revision''' (2.4.1): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.

When referring to a major release in general, only the first two digits should be used, i.e. 2.6 refers to 2.6.0, 2.6.1 etc.

== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state, add a call for screenshots
##Create a "release preperations" topic at the forum and make it a "Global Announcement", add a call for screenshots
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next, fgrun/next and fgdata/master to an even number (2.9.0 -> 3.0.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear+fgrun) and master(fgdata)
##Tag (annotated) flightgear, simgear, fgrun and fgdata with <tt>version/3.0.0</tt>
##:<code>git tag -a version/3.0.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git branch release/3.0.0</code>
##On the next/master branches, bump up the version-number of simgear, flightgear, fgrun and fgdata to an odd number (3.0.0 -> 3.1.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear, fgrun and fgdata with "version/2.9.0"
##:<code>git tag -a version/2.9.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream
##:for flightgear, simgear, fgrun and fgdata: <code>git push origin release/3.0.0</code>
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.1.0</code>
##Declare dev-streams "open" or "green"
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/3.0.0 branches of simgear, flightgear, fgrun and fgdata and push the tags.
##:for flighgear, simgear, fgrun and fgdata: <code>git tag version/3.0.0-final</code>
##:for flighgear, simgear, fgrun and fgdata: <code>git push origin version/3.0.0-final</code>
##Merge the branch release/3.0.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear, fgrun and simgear:
##:<code>git checkout -b master origin/master</code> or <code>git checkout master</code> if you already have the local branch
##:<code>git merge version/3.0.0-final</code>
##:<code>git push origin master</code>
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.

== To bump up the version number ==
* [https://gitorious.org/fg/fgdata FGData]
** edit the ''version'' file
* [https://gitorious.org/fg/simgear SimGear]
** edit the ''version'' file
* [https://gitorious.org/fg/flightgear FlightGear]
** edit the ''version'' file
* [https://gitorious.org/fg/fgrun FGRun]
** edit the ''version'' file

== Definition of repository states ==
{| class="wikitable"
!
! State
! Description
|-
! [[File:Traffic light green.png|20px]]
! Open/Green
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
|-
! [[File:Traffic light yellow.png|20px]]
! Frozen/Yellow
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.
|-
! [[File:Traffic light red.png|20px]]
! Closed/Red
| Nothing shall be pushed to the development streams (simgear, flightgear, fgrun and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.
|}

== Bug fix committing policy ==
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

== Bug tracking ==
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.12.0 the list of fixed bugs].

=== Tasks and owners ===

The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.

{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
! Status for [[Changelog 2.12|2.12]]
|-
! rowspan="7" |
| Announce the state-change of the dev-streams, '''cross-post to JSBSim list''' (see lessons learned!)
| TorstenD
|
|-
| Create/maintain the git branches
| TorstenD
|
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Sync the language files so they can be translated
| ThorstenB, James
|
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|
|-
| MacOS
| Tat/James
|
|-
| Distribute files to download servers
| Curt
|
|-
! rowspan="3" | Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
| Generate aircraft page
| Curt, Gijs
|-
|-
| Tag the [http://wiki.flightgear.org/index.php?title=Talk:Next_newsletter&action=edit&section=45 newsletter template] according to the released version
<nowiki>[[Category:Changes after 2.12]]</nowiki>
| Hooray, Gijs, Stuart (other wiki admins)
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Next Changelog]]
| All developers/contributors
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

== Open items, questions ==
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it."<ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* <del>Automate the creation of Windows and Mac installers</del> {{Done}} <ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40650.html</ref> (see [[FlightGear Build Server]])
* Automate the creation of FGDATA distribution
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests <ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
{{Cite web |url=http://sourceforge.net/p/flightgear/mailman/message/31762085/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki> |author=Anders Gidenstam |date=2013-12-17 19:46:48}}
</ref>

== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.

{{Appendix}}

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Talk:TerraGear scenery build server

2014-02-15T21:10:46Z

Flyhigh: /* Packaging (saiarcot895 ) */