GCC 9 and 10 depend on MacPorts Clang

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

A few months ago, GCC 9 started to ​depend on MacPort Clang.
This behavior has been ​copied into GCC 10.
Is there a way to avoid this behavior, at least on newer systems?

According to the comments, GCC 9 and 10 must use the same compiler as the assembler used by cctools (e.g. macports-clang-7.0 on newer systems).
However, there is no guarantee that cctools will use macports-clang-7.0 due to the multiple variants.
Is the use of ​active_variants PG necessary?

I would be happy to work on this issue, but I need a little more insight into why the change was made in the first place.

[kencu (Ken)]

Due to a number of reported assembler errors (& numerous tickets) when trying to compile newer code with gcc (Fortan, mostly, as I recall), the assember in the cctools port was tweaked to call clang as the assember if it was installed, instead of using the built-in ancient gas assembler. A specific MacPorts clang was baked in, and if not that, a suitable system clang if new enough, and if not that, then fall back to gas as previously.

<​https://github.com/macports/macports-ports/commit/7aa2ff679e61f923475b6c2a56958da61205430b#diff-b4eaceceeee7a044c27192b65d64a2a9>.

I suppose it was later decided to make sure a version of clang was available that gcc9+ could use, but I would think that is a more debatable change.

[kencu (Ken)]

Josh put a lot of thought into this. Jeremy was initially worried about a circular dependency, but after looking it over, seemed OK with it (as least didn't have any untoward comments to make). And of course Chris has been trying to make it all work as smoothly as possible for those who don't have our expertise in the underpinnings of how this stuff works.

[jmroot (Joshua Root)]

I can understand the clang dependency on 10.6 and older because without it gcc has no reasonable assembler to use. On newer OS versions it's less necessary but may still be needed to allow using certain newer instructions. And yes, you are correct that there's no real guarantee that gcc is depending on the clang version that cctools will try to use. Maybe we need clang variants for gcc (argh) with the default changing based on the installed cctools variant? Or maybe the solution is to only offer one configuration of cctools on each OS version.

[kencu (Ken)]

On 10.6.8 I use cctools +llvm7 to get a very modern assembler. It would be a shame to try to force everyone down to clang-3.4 in the name of making it simpler.

Come to think of it, every Intel system < 10.9 on MacPorts has to have clang-5.0 installed at present to be functional anyway, so we could at least use that as the floor.

[cjones051073 (Chris Jones)]

As Ken has already stated those lines in the gcc port where needed as at some point gcc9 would not build if the ancient gnu as fall back, used by as from cctools if nothing better is available, was actually used. The first thing to try is to check if this is still the case, so remove those lines, remove macports clang (so cctools will not find it) and see if gcc9 builds. Its not uncommon for issues in the snapshot gcc builds to be gone come the final pro release.

[cjones051073 (Chris Jones)]

One thing I really did not like much about those lines I added to the gcc port was the need to mirror the same logic in terms of the clang versions as used in the cctools port. It would not remove the dependency of gcc9 on a mp clang, but if we could reduce those options that would be good. Would it be possible, for each, to just use clang 7 ( or perhaps 8 now) across the board there ?

[cjones051073 (Chris Jones)]

I've improved the logic of the clang version selection in ​https://github.com/macports/macports-ports/pull/4264

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to cjones051073:

I've improved the logic of the clang version selection in ​https://github.com/macports/macports-ports/pull/4264

Thank you for working on this.