Preflight checks for 3.16 (Backport #11275)

[ffaf1]

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? No. If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ffaf1]

@geekosaur Am I supposed to bump cabal-install Cabal deps in this PR?

We do not yet have 3.16.1.0.

Maybe the bump is to be done in Bumping version numbers?

[geekosaur]

This still needs to be bumped so it is 3.16.1.0, at which point the constraint in cabal-install.cabal must be bumped so the just-bumped Cabal will be used.

[ffaf1]

Yes, but should this be done in this step? @ulysses4ever

[geekosaur]

It belongs in "bumping version numbers". I'm just reminding everyone that it needs to be done so we don't release something that will fail cabal install cabal-install.

[ffaf1]

Thanks. CI is failing, I am not sure why, I will investigate.

[ulysses4ever]

: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/runner/.cabal/store/ghc-8.8.4/text-2.0.2-73e0cbc1f5a5346d1a9036b2d38d2fb68d33283191eb8b1a2333cc976d3902db/lib/libHStext-2.0.2-73e0cbc1f5a5346d1a9036b2d38d2fb68d33283191eb8b1a2333cc976d3902db-ghc8.8.4.so)

this doesn't look good

[geekosaur]

I would suggest flushing the cache, but we go through our allotment so quickly that it happens by itself. Which makes me wonder if one of their runners is running a different version somehow. (I note that other GHC versions succeeded, and it's specifically the text package it doesn't like… but that's a bootlib. And that it's the older GHC versions that are failing, suggesting a libstdc++-*-dev update in 24.04 that dropped an older API.)

Sadly I'm running 25.04 currently so I can't really check this locally. All I can suggest is that those versions may need to be tested on 22.04 instead.

[geekosaur]

Okay, this is odd: I checked my system and GLIBCXX_3.4.32 (and quite a few older GLIBCXX_3.4.x versions) is still supported in my /lib/x86_64-linux-gnu/libstdc++.so.6. You would think 25.04 would be more likely to drop older versions than 24.04….

[geekosaur]

Oh, ugh, even worse: they're already on 22.04. I'm tempted to suggest asking GitHub what's up.

[geekosaur]

bitsandbytes-foundation/bitsandbytes#1663

[Bodigrim]

: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/runner/.cabal/store/ghc-8.8.4/text-2.0.2-73e0cbc1f5a5346d1a9036b2d38d2fb68d33283191eb8b1a2333cc976d3902db/lib/libHStext-2.0.2-73e0cbc1f5a5346d1a9036b2d38d2fb68d33283191eb8b1a2333cc976d3902db-ghc8.8.4.so)

(I note that other GHC versions succeeded, and it's specifically the text package it doesn't like… but that's a bootlib.

• It's not text specifically: https://github.com/haskell/cabal/actions/runs/19291568205/job/55325515209?pr=11280#step:13:319 has a similar error for alex (although about GLIBC, not GLIBCXX):

  /home/runner/.cabal/store/ghc-9.2.8/alex-3.5.4.0-e-alex-8af23425ba1b6ec339e6a8f702f359ec90b4d99da9e627a82f34d37e3fe16a27/bin/alex: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /home/runner/.cabal/store/ghc-9.2.8/alex-3.5.4.0-e-alex-8af23425ba1b6ec339e6a8f702f359ec90b4d99da9e627a82f34d37e3fe16a27/bin/alex)

• GHCs before 9.4 used to have text-1.2 as a boot lib. Something in the build plan forces it to try and build against text-2.0+. You can try restricting it if impl(ghc < 9.4) build-depends: text < 2 or force --constraint 'text -simdutf', but given another failure with alex and GLIBC it's not the root cause.

[geekosaur]

Yeh, I saw the alex failure as well, which is why I'm digging at shared object versioning.

[Bodigrim]

• Something in the build plan forces it to try and build against text-2.0+.

It's cabal-validate.cabal:

cabal/cabal-validate/cabal-validate.cabal

Line 45 in fbc055e

, text >=2 && <3

I suggest relaxing this to text >=1.2 && <3. It would not cure the problem here, but it will speed up builds (by virtue of not rebuilding text but reusing one from boot libraries).

[geekosaur]

Okay, now I'm really confused. I saw @ffaf1 restarted CI a couple times to see if the failure was transient. But now it's passing, and what I added can't possibly have affected the build (it just does a grep into the CI log). WTF?

[geekosaur]

I'm going to hate myself (or more likely GitHub) for this, right?

[geekosaur]

Okay, I have zero idea what GitHub changed to either cause or fix the problem, but it does appear to be fixed. @ffaf1, maybe push this in before they break it again? 😁