Make gcc14 the primary version on Tiger+ #26655
Conversation
Unlike Tiger :D I'm very happy to test this on my very real iMac G4 running 10.4.11 |
|
Looks good except building each new version of the compiler is such torture, especially on vintage PowerPC CPUs. |
|
@glebm First of all, thank you for raising this, I really hope it finally gets done. At least from gcc11 everything was working fine, there is no need to be stuck at gcc7. There are a few other spots in the port tree where defaults should be changed accordingly (R port and R portgroup, for example). But that can perhaps be done in a follow-up. @kencu mentioned elsewhere that an “activation hack” should be added (because libgcc7 is no more a full runtime). Something like this barracuda156@31fadd1 (obviously, changed to gcc14 from gcc13, this is an old commit). He knows better how to do this correctly, so hopefully he chimes in here. |
@aeiouaeiouaeiouaeiouaeiouaeiou It is by far not the worst thing to rebuild. But it will be useful to have separate revisions for archs in cases when a change is relevant only for some. It happened many times that gccs were revbumped across the board for a fix relevant to a single arch or only to clang builds. That is a waste. |
|
Somewhat on a side note, but related: it makes sense to backport a fix for |
I'm hoping that eventually at least the compiler binaries can be uploaded to packages.macports.org for 10.4 and 10.5.
Please send PRs against my branch with other things that need to be done because I really have no idea know what I'm doing!
Can you perhaps send the patch as a separate PR? This PR can wait until that patch is merged. |
|
Pushed an activation hack, hopefully I did correctly |
|
Pushed 2 more commits updating gcc-devel and r |
This patch is from upstream gcc commit at: gcc-mirror/gcc@1cfe4a4 Per barracuda156@, this is needed for gfortran on ppc. See macports#26655 (comment)
|
it is necessary to consider what happens with libgcc and all the gcc versions from gcc45 up. libgcc45 depends on libgcc6 macports-ports/lang/gcc45/Portfile Line 238 in e0c9413 libgcc6 depends on libgcc7… and so on, all the way to libgcc14. So either all those libgcc versions (5,6,7,8,9,10,11,12,13, and 14) have to all exist…. or …. we have to decide to not have some of them on the older systems, and then account for the missing ones in the portfile logic. Fixing them all to build is one thing. Actually building them all is a real chore. When I suggested two years ago we not have them all supported on older systems to reduce this burden, that idea was not supported. |
|
@kencu Well, what happens with those old gcc on arm64? They don’t even build, but who cares. Once gcc14 is the default, no one will need gcc7 and friends. Out of academic interest it is desirable to have everything neat, but no, there is no technical requirement here. The only real issue will be TFF/Aquafox, which currently need gcc-4.8. Solution could be a bootstrap gcc-4.8. It is still easier and needs to be built just once. |
|
it’s not just libgcc45. Take our current gcc on older systems, gcc7. We presumably want/need to still have access to that as it’s likely deeply integrated now into portfile logic innmany places. after whatever changevis done, gcc7 still needs to work, so libgcc7 needs to work. but libgcc7 depends on libgcc8, libgcc8 on libgcc9, etc to libgcc14…. |
So you’re basically proposing every gcc be eliminated on 10.4 and 10.5 other than (currently) gcc14? That idea will never be accepted. Well, never say never I guess…. good luck selling that idea, though. |
|
What I would (again) suggest is a consensus where we only support a subset of gcc versions in macports, hopefully everywhere in macports, but at least on older systems. gcc48 is the only one that builds TenFourFox all the rest could probably be dropped (although someone may find a reason to be upset about that). this is basically what I suggested two years ago, and was not supported then. |
|
@kencu As a disclaimer, I am not gonna try selling any idea to anyone, I gave up on trying to fix the toolchain here and just maintain my own. To the matter: in 2+ years of building stuff for PowerPC I never needed anything lower than gcc10 (once that got fixed initially), with one exception – the browser (TFF), since modern Palemoon forks still need some work to get fixed. So yeah, I honestly think there is no value in carrying those, it is a waste of effort, which can be used for something better. |
On a consensus project like macports, yoy have to sell the idea to the group. fixing your own thing and then working around your specifics is fine for your own projects… I do it too. but this is an all-of-macports game change that will affect many other ports. You need buyin. |
|
you can’t use bootstrap gcc versions to replace the compilers. bootstrap gcc versions uniquely link against their own libraries. the whole reason for the libgcc cascade on macports is to avoid that, and have everything link against the same libraries (the latest). |
|
@kencu We do not need TFF to link to the latest library. It was designed for gcc-4.8. And it is the only meaningful usage of pre-10 version of gcc (honestly I can’t even remember where else another non-Apple old gcc is required). TFF can even have it bundled, so gcc-4.8 will be a build dependency. |
@kencu This does not appear to be true. The chain only goes up to libgcc8, as gcc9/Portfile and above doesn't have any This PR does not prevent anyone from adding support to other versions of GCC in the future, it only improves the current situation by adding support for GCC14 where previously there was none. |
Ah, nevermind, gcc9 has @kencu Do I need to adjust this PR somehow? Can you please send a PR against my branch? |
Ken’s concern is real, but in a scenario where someone needs an old non-Apple gcc. Then starting from gcc14 it takes more time to reach back to gcc5. IMO just nobody needs to do that ever. |
|
@kencu @barracuda156 I've pushed what I think might be the right fix (?) to skip the libgcc versions between 9 and 13 on 10.4/5 |
|
I don't understand the situation well enough to have an opinion one way or another. I just want to follow the path of least resistance (= amount of work) to getting modern gcc on Tiger by default. :) |
|
@kencu For a note, GCC upstream does not support versions before gcc10, which means that any fixes will need to be backported, and nobody does that, as a matter of fact. How many fixes were borrowed into gcc7 port from upstream master in past two years? Not looking at the history I would say it is zero :) |
yeah, we have used gcc10-bootstrap for somethings. I'm just trying to keep the list of gcc versions we have to support as short as possible, and libgcc9 means we have to support building gcc9. |
|
but it could be gcc10 is the stepping stone. libgcc10 and newer, up to libgcc13, are stubs anyway now I believe, so that is in some ways easier. |
No objective data yet. Just history of watching how builds fail with newer compiler versions. |
|
Can I get you some objective data? Maybe you have a suggestion, it's not like this machine is being used for anything else so I can just have it build some more things if it can get us some concrete information. |
|
Got a build error for libgcc14: |
|
@glebm Wait, this may not be a great idea to depend on I would rather open an issue with gcc (upstream or Iain’s repo) to fix this for 10.4. P. S. However, I recall that someone on MacRumors successfully installed gcc14 on Tiger. Not sure when this bug was introduced. @AJenbo This is on 10.4, right? |
|
@barracuda156 Yes, this in on 10.4. I've now added |
This patch is from upstream gcc commit at: gcc-mirror/gcc@1cfe4a4 Per barracuda156@, this is needed for gfortran on ppc. See macports#26655 (comment)
gcc7 is obsolete at this point and fails to build a lot of software. Enables gcc14 for all platforms as sets it as default. gcc14 is built using gcc10-bootstrap on 10.4 and 10.5. This does not enable other versions of gcc between 9 and 14 because there doesn't really seem to be a reason to use those given that gcc14 is available (this can be revisited later if turns out that someone needs those other versions).
Without it, we get the following build error:
../libgcc/gthr-default.h:65:31: error: 'PTHREAD_RWLOCK_INITIALIZER' undeclared here (not in a function)
This patch is from upstream gcc commit at: gcc-mirror/gcc@1cfe4a4 Per barracuda156@, this is needed for gfortran on ppc. See macports#26655 (comment)
10.4.11 with the latest security updates and all. Fresh installation + Xcode ... well tigerbrew was installed, but I disabled it before trying out MacPorts. |
| @@ -233,6 +233,12 @@ if {${subport} eq "libgcc7"} { | |||
| depends_lib-delete port:zlib | |||
| depends_build-append {*}${depends_lib} | |||
| depends_lib port:zlib | |||
| } elseif { ${os.major} < 10 } { | |||
There was a problem hiding this comment.
so we aren’t doing do this skip now.
the decision was that libgcc7 will depend on libgcc8, and then etc to the current libgcc14, just like all the other systems
There was a problem hiding this comment.
Yeah, I haven't addressed this yet, as I'm still building gcc14. Will do
| @@ -8,9 +8,10 @@ if {${os.major} >= 10 || [option os.platform] ne "darwin"} { | |||
| lappend compilers macports-gcc-14 macports-gcc-13 macports-gcc-12 macports-gcc-11 macports-gcc-10 | |||
| } | |||
|
|
|||
| # GCC 9 and older only on OSX10.10 and older | |||
| # GCC 14, GCC 9 and older only on OSX10.10 and older | |||
There was a problem hiding this comment.
we are also going to use gcc10 on older systems as a fallback compiler. I can’t see enough code in this PR right now to make sure that is set right, but on older systems it needs to be in the mix to allow that
There was a problem hiding this comment.
As I understand from previous discussion, gcc10 is only used on older systems via gcc10-bootstrap in older to compile gcc14.
For the non-bootstrap compiler, the list of newer compilers is gcc9 and gcc14, right?
There was a problem hiding this comment.
I suggested gcc9, but @barracuda156 argues hard for gcc10 instead, so I aquiesed.
There was a problem hiding this comment.
@kencu Are we talking about the compiler or runtime? gcc10 is a better choice for either, but having an extra compiler imposes zero burden on users, since it is optional anyway, while having an extra libgcc in the chain is a burden, and those with slower hardware will be unhappy. As long as someone insists on having libgcc9, I do not think in makes much sense to force everyone build libgcc10 as well.
P. S. My concern was that nobody used gcc8/gcc9 on powerpc, so we just have no idea if it works at all (if you have tested it, I take your word for it, but myself I never did). To put it differently, if I needed to go down to a gcc below 14 to build a port which I personally use, it will never be gcc9. I recall gcc12 had some annoying issues (probably fixed since then, but impression stayed), so my preference would be gcc14 > gcc13 > gcc11. I only used gcc10 as a bootstrap port, but that works very well, so I have nothing against it.
There was a problem hiding this comment.
OK, great! Very glad to hear that we won't have to implement gcc9 support.
We already have gcc10-bootstrap, I'm guessing getting the non-bootstrap version to work won't be too difficult.
There was a problem hiding this comment.
It should be in zipped file in the folder mentioned
There was a problem hiding this comment.
Ah, I see. How do I figure out the list of packages from the zip file?
I've tried looking at the structure and the files in there:
$ tree libgcc9-9.5.0_2.darwin_10.i386
libgcc9-9.5.0_2.darwin_10.i386
├── +COMMENT
├── +CONTENTS
├── +DESC
├── opt
│ └── local
│ └── lib
│ └── libgcc
│ ├── libgcc_ext.10.4.dylib
│ └── libgcc_ext.10.5.dylib
├── +PORTFILE
└── +STATEBut it just seems to be libgcc itself, not a list of things that need it (other than libgcc10, and libasan5 in one of the archives).
The symbols in the dylib files don't seem particularly interesting either: https://gist.github.com/glebm/fbd9ade2caf05ab767f1900cc7412425, and they all start with _ (I think that means compiler runtime-internal).
There was a problem hiding this comment.
It's just all of libgcc9, not something that has a need for it. It's very hard to figure out what has to be investigated/tested without a concrete example.
There was a problem hiding this comment.
Still, unique needed libs, looked for by gcc9 and earlier compilers.
There was a problem hiding this comment.
So your worry is basically that setting libgcc14 as the default could break gcc7.
Since we don't know the status of gcc8-13, would it be considered blockers if they turn out to already not work?
Is there a way to list things that depends on specific GCC versions like say GCC8 or is that not relevant to what you are thinking about?
| @@ -3,9 +3,9 @@ | |||
| PortSystem 1.0 | |||
| PortGroup select 1.0 | |||
|
|
|||
| epoch 3 | |||
| epoch 4 | |||
There was a problem hiding this comment.
not sure why we are changing the epoch here. that is usually done when going down in a version, and we’re going up.
There was a problem hiding this comment.
OK, I'll revert this. The version is bumped anyway.
| @@ -40,7 +40,10 @@ checksums rmd160 91d46ec088badec75f41a2ad2a0ba228a6715107 \ | |||
| # If it is, libgcc7 installs a full runtime, otherwise it only installs | |||
| # what is missing from newer libgccX builds. | |||
| # NOTE : The logic here must match that in the libgcc port. | |||
| set isLastSupported [ expr ${os.major} < 10 ] | |||
| # set isLastSupported [ expr ${os.major} < 10 ] | |||
There was a problem hiding this comment.
the whole “isLastSupported” mechanism code can be removed from this Portfile now, right? It won’t ever be re-enabled here.
Of course, when we peg again, probably on libgcc14 for older systems, then we’ll have to add all this isLastSupported mechanism again to the one we peg at.
There was a problem hiding this comment.
Might as well get rid of the isLastSupported mechanism, noted. That'll be a medium-sized change, so perhaps it'd be more prudent to do it in a separate follow-up PR once this one has been merged?
|
The chances libgcc15 and newer, when they exist, are going to build smoothly on 10.4 and 10.5 is not high. For that reason, I’m kinda tempted to move the isLastSupported peg machanism to libgcc14, to avoid wreckage when macports moves to gcc15/libgcc15 in a few months… However, if all you keeners keep on top of libgcc-devel and make sure it works on 10.4 and up, perhaps the old systems can be kept up without that peg… |
|
@kencu I have gcc15 available for some months and libgcc15 and the main runtime on PowerPC. Today caught ICE on the new build, fixed by upstream in a few hours: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 At least on 10.5 everything should just work as well. |
|
It needs to run on all systems… Tiger and Leopard Intel (when a macports-clang is installed) is always a bigger headache. |
|
@barracuda156 …. you should be doing all the things I have had to do on this PR, including taking it to the mailing list for consenus, making sure every system builds, tweaking all the compiler selection, etc, etc, etc. You approved this PR a while ago, but it has never been in a committable state, and still isn’t. |
I could say that you should have done all these things when I made a similar PR earlier, and everyone would have had a working setup for the past year plus already, but realistically there are no obligations here, on any side.
Firstly, this is a personal approval (at the time of making it), the very system implies that opinions may vary, otherwise there is no point in the very possibility of multiple approvals :) Secondly, when things are re-shuffled on the go, they can deviate from what was considered a desired state or at least a strict improvement. (So if someone really needs this statement, here it is: an approval at a point of time does not mean that anything after that is automatically approved.) But yeah, I think that current situation is just bad, and has been for many months. So even an imperfect fix is superior to status quo. |
|
except YOU NEVER EVER FINISHED IT. |
|
we are getting closer here now to something commitable |
|
A side note: GCC states that GCC <11 can be bootstrapped by any ISO C++98 compiler. GCC 4.2 advertises full C++98 support. One thing to try in the future is to build gcc10-bootstrap directly with apple-gcc4.2, rather than gcc7-bootstrap like we do now. |
|
I built and enabled the gcc7-bootstrap when I couldn’t get it to build with apple-gcc42, but would be delighted to find out there is a way to fix the build that doesn’t require another bootstrap compiler! |
gcc7 is obsolete at this point and fails to build a lot of software. Enables gcc14 for all platforms and sets it as default.
gcc14 is built using gcc10-bootstrap on 10.4 and 10.5.
This does not enable other versions of gcc between 9 and 14 for 10.4/5 because there doesn't really seem to be a reason to use those given that gcc14 is available (this can be revisited later if turns out that someone needs those other versions).
Before I go ahead with trying to build this (in qemu it takes a very long time), I'd like to ask someone more knowledgeable like @kencu and @barracuda156 to have a look (this is my very first PR to macports!), so I'm creating this PR as a draft.
This PR is based on what I've seen in #16843 by @barracuda156 and 9aa2182 by @kencu and is completely untested.
Description
Type(s)
Tested on
macOS 10.4.11 8S165 Power Macintosh
Component versions: DevToolsCore-798.0; DevToolsSupport-794.0
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?