272
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 15:53, 30 May 2015
, 30 May 2015→Project Focus
m (→Project Focus) |
Hamzaalloush (talk | contribs) m (→Project Focus) |
||
| Line 120: | Line 120: | ||
:: 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) | :: 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, [ | ::: 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) | : 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) | ||