I've verified that the (small) test suite still passed and had a cursory
look at the code for the bindings. cmark doesn't use any internal Text
modules nor seems to make any specific assumptions about Text's internal
encoding. The interfaces used are Data.Text.Encoding and
Data.Text.Foreign. From the latter, only functions relating to CString
are used which have used UTF-8 encoding already for text < 2.0. (It
stands to reason that cmark may actually benefit from the internal
encoding change in 2.0.)
When building gi-gtk with ghc-9.6.1 and ghc-9.6.2 there are errors
like this:
<no location info>: error:
attempting to use module ‘gi-gtk-3.0.41-DcfU7A0rbDCAyPkJQEwKC:GI.Gtk.Interfaces.Buildable’ (./GI/Gtk/Interfaces/Buildable.hs) which is not loaded
The errors can be avoided by using -j1, which is unfortunate for
gi-gtk because it has 708 modules to build.
The ghc gitlab issue is: https://gitlab.haskell.org/ghc/ghc/-/issues/23392
This applies the Cabal pkgconfig workaround to taffybar and all of its
pkgconfig-using dependencies.
A typical example of the build error looks like this:
Package libpcre2-8 was not found in the pkg-config search path.
The main problem was GHC exceeding the Hydra output limit with profiling
libs on aarch64-linux which made us disable the feature. Nowadays the
limit is 3GB, the GHC output is a bit over 2GB, so easily under the
limit.
aarch64-darwin uses a different codegen backend and was never really
affected by the problem: Its output with profiling enabled is around
1.6GB.
Consequently we can enable profiling for all platforms again, as we have
no output size issues for those we build on Hydra.
Thanks to flokli for helping me track down these up to date numbers.
Some packages cabal-install needed a certain version range (cabal-install-solver
and resolv) have versions incompatible with these in Stackage LTS 21. We can,
however, easily provide the necessary ones.
Additionally, we clean up some old resolv related overrides that are no longer
necessary or we no longer care about (being able to build cabal-install with
GHC 8.6, namely).
For GHC >= 9.0, foldable1-classes-compat is a test only dependency. For GHC < 9.0,
OneTuple also depends on it. It is important to add it to the library's build
depends as well, so it gets propagated properly to builds of packages that depend
on base-compat-batteries (or foldable1-classes-compat will appear as broken to
Cabal).
