20,741
edits
Talk:Building FlightGear - Cross Compiling: Difference between revisions
Jump to navigation
Jump to search
m
Talk:Building FlightGear - Cross Compiling (view source)
Revision as of 08:02, 8 June 2015
, 8 June 2015→fgfs backtraces
| Line 201: | Line 201: | ||
:: 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) | :: 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) | ::: 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 == | == 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) | 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) | ||