Configuration fails on OSX Monterey: "unreleased macOS version"

[pittwolfe]

Building gcc10 using MacPorts on Monterey 12.1 fails with the configuration error "configuring for an unreleased macOS version x86_64-apple-darwin21". The error is issued when processing the file gcc/config.gcc. Attempting to add what seems like the appropriate line for darwin21 eventually leads to linker errors.

This is a copy of a MacPorts bug report originally issued by Rixin Li about 2 months ago and updated on Dec 30, 2021. It was recommended that the issue be reported here. There are more details at the MacPorts trac.

The system I'm trying to compile on is macOS 12.1 (Darwin 21.2.0) with the Xcode command line tools version 13.2.0.0.1.1638488800.

[iains]

yeah, there is a queue of darwin20/21 backports needed for gcc-11, 10 and 9 (which are the open branches) ... will try to get to this at the weekend.

[jonels-msft]

Thanks for looking into it, I encountered this bug too.

[kencu]

Iain, some of these folks are very skilled and probably want to help you.

If you gave them a quick pointer to the commits in the mainline or arm64 gcc branches that needed to be backported, built, and tested, then sent up to you as PRs, I'm fairly sure they would be happy to help you out (assuming you think that would save you any time ;>).

Perhaps if they looked through those branches for the commits you have added over the past few months, they might spot the ones needed for backporting.

[iains]

OK. I have actually done the backports (cherry-picks and resolution of problems) from master .. what I need to do is to collate those into "critical" "must-have" "useful" and "icing on the cake" branches .. I would then welcome testing and PR reporting .. my machines are definitely a finite resource so any testing and bug analysis is always welcome.

.. I am terribly behind on backports at the moment - so need to give it some attention - let me see if I can do some of the stuff above this w/e ..

[iains]

can you folks clarify how you are using / want to use the GCC branch(es)?

e.g. are you:

• taking snapshots from the current GCC-10 branch (in which case you will pick this up as soon as it is applied)
• wanting a backport to the last release?

[kencu]

As many of these folks seem to be coming from MacPorts, what will be sellable there would be a single patch that we apply onto the current gcc10 distfile we are using.

That looks like a bit of a mess right now, however:

https://github.com/macports/macports-ports/blob/f8343e2b004fdfc57b5bf209f08c5f6f4fc5b31d/lang/gcc10/Portfile#L38

but at any rate, a patch or patchset onto the current release is what sells there.

[barracuda156]

As many of these folks seem to be coming from MacPorts, what will be sellable there would be a single patch that we apply onto the current gcc10 distfile we are using.

That looks like a bit of a mess right now, however:

https://github.com/macports/macports-ports/blob/f8343e2b004fdfc57b5bf209f08c5f6f4fc5b31d/lang/gcc10/Portfile#L38

but at any rate, a patch or patchset onto the current release is what sells there.

That would be awesome, especially if PowerPC also included, as the existing Macports gcc10 does not build on 10.5.8.

[iains]

OK. we definitely do not need separate branches for x86 and ppc *** - I made the 10-3-ppc branch as a quick fix.

As I've possibly proposed before, the logical solution is to have a gcc-N.M-darwin branch (this is exactly what the Linux 'vendor' branches do) that has back ports considered critical or highly valuable to the platform (possibly including non-regression fixes).

I suppose that whether the Darwin 'distros' build that, or make a patch from it against the gcc-N.M release is academic.

Whilst we do not want churn in release branches, we must accept that sometimes an additional fix is considered necessary.

@fxcoudert .. I guess you kinda do this anyway?

In any event, as mentioned before in this thread, because we have been putting maximum effort into aarch64-darwin, there is some back porting work to do on 11.x and 10.x, plus we really need to sort out the libstdc++ debacle since C++11+ projects need this to work.

So I will certainly shout when some help is needed - but for now I have most of the patches cherry picked onto 11.2 and 10.3 - it is a question of deciding which are considered critical and producing a composite branch.

---

(arm64 on 10.x is highly experimental, and therefore would require something different - which is highly likely to change as we finalise the master version).

[barracuda156]

OK. we definitely do not need separate branches for x86 and ppc *** - I made the 10-3-ppc branch as a quick fix.

@iains For the time-being, what would be a correct way to use your gcc10 within Macports environment? If that is done, it gonna fix multiple problems (since at the moment macports-gcc-7 fails to build for ppc64).

[iains]

I am not familiar with how the mac ports environment works (I'm not the right person to ask about that), I suppose you have designations for multiple compilers? .. in which case you can invent one for the gcc-10.3?

BTW, I am still not sure why gcc-7.5 doesn't build for ppc64 - perhaps you can start a different thread on my gcc-7 repo (or in the toolchain discussion)

[kencu]

OK. we definitely do not need separate branches for x86 and ppc *** - I made the 10-3-ppc branch as a quick fix.

@iains For the time-being, what would be a correct way to use your gcc10 within Macports environment? If that is done, it gonna fix multiple problems (since at the moment macports-gcc-7 fails to build for ppc64).

That will turn out to be a mess, to be honest... the assembler and linker will be all set up wrong for MacPorts cctools. The libgcc will be wrong, so the software you build will be linked all over the place.

Don't do it.

If you absolutely insist on doing it, look at the "port select gcc" mechanism, which sets up various symlinks to the default gcc, and then look at how to force that to be used when building software.

But -- my advice -- DONT DO IT!

[kencu]

I am not familiar with how the mac ports environment works (I'm not the right person to ask about that), I suppose you have designations for multiple compilers? .. in which case you can invent one for the gcc-10.3?

BTW, I am still not sure why gcc-7.5 doesn't build for ppc64 - perhaps you can start a different thread on my gcc-7 repo (or in the toolchain discussion)

Macports is building nearly nothing as ppc64, so it is extremely untested. The problem is probably something to do with one of the supports (mpc, isl, etc) or perhaps the cctools/ld64 we are are using at the moment (we don't use the default system cctools or linker for anything much in MacPorts).

[iains]

Well, I always build and test the ppc64 multilib -- it definitely does work with the default cctools and ld64.

If it's broken with the later cctools and/or ld64 - then I suspect you are missing patches (or using a version of ld64 that doesn't support ppc64). but please lets shift this conversion to https://github.com/iains/darwin-toolchains-start-here/discussions

[kencu]

Once you get a working gcc10/libgcc10 that will reliably build on 10.4 and 10.5 PPC and Intel on MacPorts (and that is a ways off) then you can get the default gcc/libgcc upgraded on those systems to gcc10/libgcc10 in a formal, official, organized way like I did last year when I bumped 10.6 to gcc11/libgcc11.

Then you have a coherent plan that will be fully supported by everyone, and you can move ahead.

Fixing gcc7/libgcc7 to build working ppc64 software is a much easier plan -- some hacking to figure out what is wrong by someone who knows how to debug the issue is needed.

[iains]

GCC 10 (and 11) is well-tested (by me) on 10.4 and 10.5

I have stopped testing 10.4 on GCC-12 (but that's just because it takes a long time on the hardware I have)

[barracuda156]

Well, I always build and test the ppc64 multilib -- it definitely does work with the default cctools and ld64.

If it's broken with the later cctools and/or ld64 - then I suspect you are missing patches (or using a version of ld64 that doesn't support ppc64). but please lets shift this conversion to https://github.com/iains/darwin-toolchains-start-here/discussions

Opened discussion here for Macports and ppc64: https://github.com/iains/darwin-toolchains-start-here/discussions/8

[fxcoudert]

Answering to explain Homebrew's position because I was summoned 🧙: we ship upstream releases unpatched, as much as possible. We ship critical patches, but only to the latest released version. So, for gcc 10, we don't apply any patch, but we only ship it on Mojave, Catalina, and Big Sur… not Monterey.

And in general, we prefer well-identified patches (in small number) that apply on top of existing releases, rather than building from a different branch. But if a branch is provided, I'll deal with identifying the patches that we want to ship ;)

What we aim at (and I think @iains will agree) is keeping the different with the released version as small as possible.

[iains]

The maintainers (not just me) make quite some effort to back port fixes for regressions (and in some cases, wrong code, or wrong configuration).

unfortunately, both 10.3 and 11.2 are nearing the end of their cycle - so that there is quite some difference between 10.3 and the tip of the 10.x branch.

This can make it quite hard to pick one or two patches and apply them to 10.3 (or 11.2) because those changes might well depend on other back ports.

So, yes, I do agree with @fxcoudert that it is desirable, ideally, to make the additions small (and this is usually quite easy when they are small changes close to the branch dot release point). However, when we are further away from a dot release (in elapsed time and applied regression fixes), perhaps a better model is to build a snapshot of the branch [so 10.3.1-xxxxxxxx] so that one gets the complete set of backports that have been processed more widely through CI. [This assumes that the needed critical fixes have been back ported of course]

Anyway, progress-wise, over the weekend I cherry-picked a bunch of Darwin changes onto 10.3 and confirmed that builds OK on Monterrey - so I need to trim list down and actually apply to the branch [after testing more widely including on Linux] - then we can get a set for 10.3.

For 10.3 I think that the changes for Monterrey are going to be reasonable, we'll have to see what set is needed for earlier branches.