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