At least some of the buildbot ghc builds might be fixable — one of them failed due to a missing png-config I believe, for example.
Because of the way upstream builds ghc on macos, their older system support has become more limited. They use homebrew, and current systems, with an older deployment target set. This has become less viable to run on older systems as time goes by. It is possible to build up from older versions of ghc on an older system, however… and by doing that, with a couple of tiny patches, for strnlen etc, and stepping up system by system, up to the current ghc 9.4.4 runs as far back as 10.6 at least, and maybe could be made to work on 10.5 Intel. i386 builds had bitrotted last I tried, as had ppc builds, so I gave up on those arches. Once you have ghc, you can bootstrap a build of cabal-install from the bootstrap folder in their git repo. Legacy-support is required. I have several current cabal versions running back to 10.6 anyway, though, that could be used instead of bootstrapping cabal. These are available in the repo below. Once you have cabal, you can build a version of stack using cabal from the stack git repo. Because of the way stack downloads current ghc versions from upstream, much of stack won’t be usable anyway, although you can override the ghc selected (works), add legacy-support, and sometimes it will build something that cabal won’t build. Then you can build most of what you want, like pandoc and shellcheck. There will be occasional minor patches needed to “cbits” parts, though, in some packages. I have this working locally, but have not Portfiled it. Binaries and some initial instructions are here: https://github.com/kencu/ghc-for-older-darwin-systems https://github.com/kencu/ghc-for-older-darwin-systems/releases/tag/9.4.4 I did find one minor hiccup building something on 10.7 one time, where the emutls symbol used on 10.6 for TLS was not found when building something using TLS on 10.7. I didn’t sort that out as yet. Is it something that could be Portfiled? Sure, anything can be. I haven’t approached that as yet. Perhaps it would be acceptable to make the binaries of pandoc and shellcheck that run on older systems available? Usually this is not considered OK, but .. I’ll work on it some more as I get time. Building the most current pandoc is stuck at the moment as it uses Template Haskell in one of its support packages, and there is a linker error occurring related to that. Debugging the builds of ghc software is harder than clang or gcc builds… everything is quite different, often. Ken
