Building FlightGear - Cross Compiling: Difference between revisions

Jump to navigation Jump to search
m
→‎osg-earth compilation trouble: obviously solved - congrats !
mNo edit summary
m (→‎osg-earth compilation trouble: obviously solved - congrats !)
Line 791: Line 791:
* 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.
* 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.
* 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.
=== osg-earth compilation trouble ===
''SOLVED''
osg-earth has both CMake and autotools generators provided by source, i'm using a basic CMake config:
<syntaxhighlight lang="make">
PKG            := osgearth
$(PKG)_IGNORE  :=
$(PKG)_VERSION  := 2.6.1
$(PKG)_CHECKSUM := 4c68efb9e413a5d78fffa2142e3e2998d3535939
$(PKG)_SUBDIR  := gwaldron-osgearth-350f1a0
$(PKG)_FILE    := gwaldron-osgearth-350f1a0.tar.gz
$(PKG)_URL      := https://github.com/gwaldron/osgearth/tarball/osgearth-2.6
$(PKG)_DEPS    := gcc openscenegraph curl gdal geos
...
define $(PKG)_BUILD
    mkdir '$(1).build'
    cd '$(1).build' && cmake '$(1)' \
        -DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)'
    $(MAKE) -C '$(1).build' -j '$(JOBS)' install VERBOSE=1
endef</syntaxhighlight>
i'm getting GEOS related undefiend references, see: [https://trac.osgeo.org/geos/ticket/552]
<syntaxhighlight lang="bash">CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0xb0): undefined reference to `geos::geom::PrecisionModel::~PrecisionModel()'
CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0x20b): undefined reference to `geos::geom::Coordinate::Coordinate(double, double, double)'
CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0x649): undefined reference to `geos::geom::GeometryFactory::getCoordinateSequenceFactory() const'
CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0x792): undefined reference to `geos::geom::GeometryFactory::getCoordinateSequenceFactory() const'
CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0x7d3): undefined reference to `geos::geom::GeometryFactory::getCoordinateSequenceFactory() const'
CMakeFiles/osgEarthSymbology.dir/objects.a(GEOS.cpp.obj):GEOS.cpp:(.text+0x846): undefined reference to `geos::geom::GeometryFactory::getCoordinateSequenceFactory() const'
collect2: error: ld returned 1 exit status
make[4]: *** [lib/libosgEarthSymbology.dll] Error 1</syntaxhighlight>
stock [https://github.com/mxe/mxe/blob/master/src/geos.mk geos.mk] shared libraries is bieng built with these options: "-pedantic -ansi", there is also an [https://github.com/mxe/mxe/blob/master/src/geos-1-fixes.patch MXE patch applied] to fix static builds too, might be a hint.
* seems name-mangling related: are you seeing the corresponding symbols in the object files (use '''nm''') ?
:: i'm getting the class name, but unlike other symbols in the same library, i do not get the function getter. [http://pastebin.com/0zNn3P23]
* if geos has any tests/demos (aka make check), do those work/compile against geos or not ?
:: there is the test case tinyxml that is provided with the source, that the bug above the post has failed to compile against. i'll try that.
* is this specific to the compiler (static/dynamic) used here, or are you getting the same errors when building with your native compiler instead ?
:: native compiler produces the getter, wierd. see [http://pastebin.com/x0JF9h2E], something is not exporting all symbols? CMakeLists? good eye.
* is this affected by the version of osgearth and/or geos used ? If in doubt, I'd use the version that poweroftwo suggested in his tutorial
:: alright, will look into that.
: if that doesn't help, I'd try to revert to osgearth/geos from ~6 months ago and if that makes a difference I'd run git bissect to see what is causing this. Obviously, it would help to have a less complex test case than osgearth, i.e. a geos demo/examples that has the same problem, so if the xmltester snippet works, I'd use that for git bissect. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:59, 31 May 2015 (EDT)
PS: The suggested fix I found for this particular problem (i.e. xmltester) is reverting the patch discussed at [https://trac.osgeo.org/geos/ticket/319] - so we may need to review the patch and apply it to the geos/osgearth code via a mxe/mk patch if that works ... According to google, tthe other thing worth checking seems conflicting geos versions installed (e.g. system-wide or elsewhere)
:: yeah, i tried reverting the patch, as well forcing to compile against c++89/90 as make argument, their fix with the last patch was to force "-pedantic -ansi off" for the failing object.
Same error, same software, solution here is linking order related and requires adding another geos lib (-lspatialindex): https://github.com/ablimit/hivesp/issues/3#issuecomment-40071814
{{Building}}
[[Category:Core developer documentation]]

Navigation menu