The path to Haskell is paved with good intentions—there’s a ticket for this now because pandoc stopped building on some older systems after I specified stack as the build tool: https://trac.macports.org/ticket/66764
Back to cabal. > On Jan 25, 2023, at 11:29 AM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: > > 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 <steve.t.sm...@gmail.com> 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 <ken.cunningham.web...@gmail.com> >>> 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 >>> >>> >
smime.p7s
Description: S/MIME cryptographic signature
