Stack from MacPorts doesn’t build on snow leopard, and I don’t recall it ever built in previous years.
The port health page can be pretty misleading, to be honest. You can get a much better idea of what is really building here: https://packages.macports.org/stack/ https://packages.macports.org/ghc/ Ken > On Jan 25, 2023, at 7:27 AM, Steven Smith <[email protected]> wrote: > > I’d recommend starting with the low-hanging fruit. These are all stack-based > builds, and stack can build itself back to Snow Leopard: > https://ports.macports.org/port/stack/details/ > > Why doesn’t stack-based pandoc also build back to Snow Leopard? Is this a > MacPorts issue or a Haskell-world issue? > >> On Jan 24, 2023, at 11:56, Ken Cunningham <[email protected]> >> wrote: >> >> 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 >> >>
