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 16:31, 30 May 2015
, 30 May 2015→Project Focus
m (→Project Focus) |
|||
| Line 127: | Line 127: | ||
::: 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) | ::: 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) | |||
== .deb packaging == | == .deb packaging == | ||