Upgrading gcc and binutils
ryandesign opened this issue · comments
Retro68 currently bundles gcc 9.1.0 (released 2019-05-03) and binutils 2.31.1 (2018-07-18). The latest stable versions are gcc 12.2 (2022-08-19) and binutils 2.39 (2022-08-05). Is it possible to upgrade the versions Retro68 uses, or is there a reason that wouldn't work or would be undesirable?
An advantage that Retro68 gets by using its current gcc is that it supports C++11. This advantage could potentially be improved upon with better support for C++14, C++17, C++20 and future C++ standards by upgrading to a newer version.
Newer gcc and binutils versions might also offer better support for newer host operating systems. As of the version of clang included with Xcode 12 (2020-09-17), implicit declaration of functions is an error, and compiling the currently-bundled versions of gcc and binutils with Xcode 12 or later produced numerous "implicitly declaring library function" errors in the config.log which might be making some configure tests produce inaccurate results. I patched the configure scripts to fix this but hopefully newer versions have fixed it already.
Maybe the thing to do is to upgrade just one of them to the next version chronologically (for example, to binutils 2.32 (2019-02-02)). And then a little later, upgrade the next thing. That way, changes between versions are minimized and if problems occur it's easy to check previous Retro68 commits to see if the problem was introduced in a particular gcc or binutils version.
Do you have any concerns about upgrading gcc or binutils to a newer version? For example, are you aware of any features that have been changed or removed which might impact Retro68?
Do you have an established/documented method for upgrading gcc or binutils? I expect that the method would be to get a diff between e.g. original copies of binutils 2.31.1 and 2.32, apply that diff to the Retro68 version of binutils 2.31.1, resolve any conflicts, and review the changelog for any changes that might need to be reflected in Retro68's modifications.
No specific concerns yet, except that it will mean that I need some extra backported software to run things on my PowerMac G5.
Established method: mostly, documented: no.
The basic approach is to update things on the upstream branch in the git repository and then resolve conflicts.
Git mostly saves us from manually getting & applying the diffs :-)
I will see if I can get around to having a go at an upgrade this weekend, I've got a few days off work so I might be relaxed enough to tackle it by then ;-) [no promises though]
No specific concerns yet, except that it will mean that I need some extra backported software to run things on my PowerMac G5.
What would you need?
The basic approach is to update things on the
upstreambranch in the git repository and then resolve conflicts. Git mostly saves us from manually getting & applying the diffs :-)
If you understand how to use git to do that, that pleases me! I've been trying to understand Git for six years and it is still difficult for me.
I will see if I can get around to having a go at an upgrade this weekend, I've got a few days off work so I might be relaxed enough to tackle it by then ;-) [no promises though]
Thanks! That would be great. I have no specific need for a newer version at this time—the current versions are working great for me—I just recall countless prior situations where an update of macOS or Xcode or some other external change like the introduction of Apple Silicon broke the compilation or functioning of some software, and the more outdated the software was, the harder it was to fix.
Work is in progress in branch gcc12-update.
Lots of things are currently broken, will still take a bit of time :-)
(probably among other things: "\pPascal Strings", some 68K relocations, something about multisegment support, and the result image of Raytracer2 on PPC is wrong).
If we could get some of these changes merged back upstream (to GCC and binutils), so that there are fewer differences whenever a new merge needs to be made, I'd think that would be cool
Work is in progress in branch gcc12-update.
Lots of things are currently broken, will still take a bit of time :-)
I see this work was merged to the master branch and the readme now says it uses binutils 2.39 and gcc 12.2.0. Are things still broken or are they working sufficiently to consider this update completed and this ticket closed?
Things seem to work now.
... so its time to start porting to gcc 14 ...