Use gcc14 on Darwin aarch64 #81
Comments
|
So the initial problem is that this doesn't currently build: There may also still be issues with building on 12.3 which is what my current binary package set uses. So I'd rather wait a few days and see if I can resolve this next week, unless you have time in the meantime. |
|
Ooops, yeah. I forgot that Adam's patches didn't make it into the dreckly fork, and my gcc14 was installed manually from wip on my M1. So currently, there is no gcc package in dreckly that works on Darwin-aarch64. |
|
gcc12 does, which is what ships in my binary package repository currently, but only on older macOS releases. |
|
What approach would you suggest to support modern releases? I think you suggested separate packages for Darwin, maybe do that based on Iain's branches, so we're not maintaining local patch sets? On the other hand, the current pkgsrc gcc14 just works, so it could at least be used as a stop-gap, assuming it works on older releases as well. Then we fix a ton of packages and can take our time devising a more sustainable solution. |
|
@jperkin Looks like patches fail to apply. It should not be too hard to fix it, given that we have a port in MacPorts which builds on every macOS and confirmed to work. P. S. MacPorts does not enable modula2 and gccrs, though both were building earlier and at least modula should still build. As I recall, they did not need any patches, simply adding to the list of langs worked. But I am not sure about the current status of these two. |
|
The problem is that the Homebrew patch set downloaded from Makefile.common: conflicts with the static patches in lang/gcc14/patches. This was discussed on the pkgsrc mailing lists back in December. The current pkgsrc gcc14 has one (large) unified patch set in the patches dir. There's a copy of it in pkgsrc-wip that I used to install on dreckly. |
|
I ran the heavily patched pkgsrc gcc14 through CI so we have a basis for comparison: https://github.com/drecklypkg/dreckly/actions/runs/13774769853 It also succeeded on my Alma8 installation. Both this package and the current dreckly gcc14 failed on macOS 12: |
|
@outpaddling Is there a log (for macOS 12 build failure). |
|
|
@outpaddling This is probably related to |
|
Yeh my plan was to have a separate build for Darwin, similar to how I have a separate build for the illumos patchset at https://github.com/TritonDataCenter/pkgsrc-extra/tree/main/gcc13. I did look briefly last week or so at seeing if there was a way to reasonably split OPSYS-specific bits from a single package but it just ends up too complicated. |
|
I'm not clear on what you mean by "split OPSYS-specific bits from a single package". Do you mean separate gcc packages for different platforms, e.g. gcc14-sun, fcc14-darwin? Or split OPSYS-specific bits within the same package? |
|
Yeh separate packages, at least for these platforms where there are huge patchsets required. It is possible to combine everything into one, and you end up with e.g. My SunOS-specific |
|
OK, good - I've been leaning toward separate packages as well, but haven't given this nearly as much thought as you have. What I was thinking: Since GCC deps are already managed through mk files, it seems like it would be pretty easy to split off a package for a particular platform. For the Darwin packages, we could look into using Iain's distfiles as upstream, so they would require minimal local patches and updates would be simple. |
|
Yeh exactly. My SunOS package uses the illumos branches on GitHub as upstream so that |
That will certainly reduce patches required, and we do want to use Iain’s branches on macOS in any case, whether directly or via patching a gcc release. By the way, is there an intent to have these merged into pkgsrc upstream? If yes, then a patch applied to an official release may still be preferable (which is what MacPorts does). If not, then using Iain’s branches directly is easier. |
|
Tracking the branches directly keeps our packages much cleaner and should be the way forward for these specific packages, consistent with our core value of maintainability. |
Yeah, that makes sense. |
That would be up to the pkgsrc package maintainer(s). There will undoubtedly be a lot of updates and fixes copied between dreckly and pkgsrc, but they are independent package managers moving in different directions. Using Iain's branches directly would also be a good way to thoroughly test his patches, and ultimately help justify upstreaming them. |
|
FYI, the gcc14-darwin package in the ci/gcc14 branch appears to work fine on my M1 and my old x86 Macbook: ProductName: macOS ProductName: macOS What remains to be done before committing it to trunk? |
This is an incremental patch to support the use of platform-specific gcc14 packages. It will have no effect until such packages are added. This only effects gfortran dependencies for now, as our only available test port is gcc14-darwin (in ci/gcc14 branch), and darwin is clang-based. We will need similar updates to gcc.mk if/when platform-specific gcc packages are created for gcc-based platforms. Also update default to gcc14 for all Darwin per discussion in drecklypkg#81.
|
It would be good if others could test https://github.com/drecklypkg/dreckly/tree/ci/gcc14/lang/gcc14-darwin on as many macOS versions and CPUs as possible. As I mentioned above, I have tested it on 12/x86_64 and 15/aarch64. We also have 13/x86_64 in CI, but that's the extent of what I can test right now. |
|
@outpaddling Since the build requires C++11 (which is correct), it must use a C++11-capable compiler, but I do not see that in the port. Is it picked based on declared C++11 standard? If not, then we know for sure it will fail on systems where Xcode compiler has no C++11 support. |
|
@barracuda156 Good point. I wouldn't worry about building gcc14-darwin directly with the native compiler on a system that old. I'm mainly concerned about avoiding regressions on recent macOS versions that I can't test. If someone really wants to use such an old OS, they' should probably just use the newest gfortran that the native compiler can build, rather than 14. Or maybe one of the same vintage as the native gcc to ensure compatibility. |
|
The correct procedure, very well tested, is to build gcc10 and use that to build gcc14. It is implemented in MacPorts, for example, and it is a way recommended by gcc upstream. We do not want some archaic gfortran, really, on any systems. And it is better to have the same primary compiler across all systems, rather than a zoo of versions. gcc14 works back to 10.4. And while specifically 10.4 is less-trivial due to Xcode toolchain issues, 10.5+ can be easily supported. |
|
There is arguably no need to re-invent a bicycle, what is needed is simply to translate existing logic in tcl into perl, and have gcc10-bootstrap port for the purpose of building gcc14 starting from Xcode with no C++11 support. |
|
@catap Kirill, would it be hard to port |
|
@barracuda156 if you use my branch it shouldn't be a big deal to be honest. The main pain was to fight with multiarch in macports :) |
|
Hopefully universal builds is not a concern here. (I gave up on them myself, it is just too broken across numerous ports.) |
If I were interested in gcc14 on an EOL macOS platform, I would probably install gcc10 in a separate dreckly tree used just for bootstrapping a second tree for general use. This would avoid adding a lot of complexity to the dreckly gcc packages that would consume man-hours, lead to more bugs, and wouldn't benefit most dreckly users. We had a discussion about this on the pkgsrc-users list years ago. |
Any objections to the following quick-fix? Since it's limited to Darwin aarch64, my only concern would be that it may not work on out-of-date macOS / Xcode installations. Not sure if anyone cares about that.
The text was updated successfully, but these errors were encountered: