So, some success. I have now managed to build pandoc on 10.6.8, and it seems to work as expected.
A small bit of unpleasant hackery is currently involved, that with any luck will be fixed upstream somehow. Exactly how to fix this upstream is not clear to me just yet: https://github.com/haskell/cabal/issues/8704 https://github.com/jgm/unicode-collation/issues/13 I still have a few packaging issues to work out (it links to MacPorts’ libz instead of the system libz, for one, and it uses 10.6.8’s version of thread-local-storage using emutls that will need to be sorted out before this binary could be used on 10.7+, but the basic plan does work. Ken > On Jan 26, 2023, at 3:28 AM, Steven Smith <[email protected]> wrote: > > 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 >> <[email protected]> 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 <[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 >>>> >>>> >> >
