Weird problem: cabal-3.6.0.0 fails to build shared executables with Assertion failed

[mouse07410]

Description

When ~/.cabal/config contains

build fails in a weird way:

$ cabal install happy
Resolving dependencies...
Build profile: -w ghc-9.0.1 -O1
In order, the following will be built (use -v for more details):
Assertion failed
CallStack (from HasCallStack):
  assert, called at src/Distribution/Client/ProjectPlanning.hs:238:5 in main:Distribution.Client.ProjectPlanning

To Reproduce

Steps to reproduce the behavior:

Edit ~/.cabal/config as shown above, and try to install anything reasonable from Hackage - like above.

Expected behavior

Something like this

$ cabal install happy
Resolving dependencies...
Up to date
Symlinking 'happy' to '/Users/ur20980/.cabal/bin/happy'

or a real build, like

$ cabal install hlint hoogle hpack hscolour
Resolving dependencies...
Build profile: -w ghc-9.0.1 -O1
In order, the following will be built (use -v for more details):
 - blaze-builder-0.4.2.1 (lib) (requires download & build)
 - base-compat-0.12.0 (lib) (requires download & build)
 - base-orphans-0.8.5 (lib) (requires download & build)
 - base64-bytestring-1.2.1.0 (lib) (requires download & build)
 - bsb-http-chunked-0.0.0.4 (lib) (requires download & build)
 - basement-0.0.12 (lib) (requires download & build)
 - byteorder-1.0.4 (lib:byteorder) (requires download & build)
 - cabal-doctest-1.0.8 (lib) (requires download & build)
 - clock-0.8.2 (lib) (requires download & build)
 - colour-2.3.6 (lib) (requires download & build)
 - cmdargs-0.10.21 (lib) (requires download & build)
 - cereal-0.5.8.1 (lib) (requires download & build)
 - data-default-class-0.1.2.0 (lib:data-default-class) (requires download & build)
 - file-embed-0.0.15.0 (lib) (requires download & build)
 .  .  .  .  .
 - hpack-0.34.4 (exe:hpack) (requires download & build)
 - hoogle-5.0.18.2 (exe:hoogle) (requires download & build)
Downloading  base-orphans-0.8.5
Downloaded   base-orphans-0.8.5
Downloading  basement-0.0.12
Starting     base-orphans-0.8.5 (lib)
Building     base-orphans-0.8.5 (lib)
Downloaded   basement-0.0.12
Downloading  byteorder-1.0.4
Starting     basement-0.0.12 (lib)
Installing   base-orphans-0.8.5 (lib)
Building     basement-0.0.12 (lib)
.  .  .  .  .
Installing   hoogle-5.0.18.2 (lib)
Completed    hoogle-5.0.18.2 (lib)
Starting     hoogle-5.0.18.2 (exe:hoogle)
Building     hoogle-5.0.18.2 (exe:hoogle)
Installing   hoogle-5.0.18.2 (exe:hoogle)
Completed    hoogle-5.0.18.2 (exe:hoogle)
Symlinking 'hoogle' to '/Users/ur20980/.cabal/bin/hoogle'
Symlinking 'hlint' to '/Users/ur20980/.cabal/bin/hlint'
Symlinking 'hpack' to '/Users/ur20980/.cabal/bin/hpack'
Symlinking 'HsColour' to '/Users/ur20980/.cabal/bin/HsColour'

System information

• Operating system: macOS Big Sur 11.6
• Xcode-13
• cabal-3.6.0.0, ghc-9.0.1 and ghc-8.10.7 (same problem with both)

Additional context

Everything (GHC, Cabal, Stack) is installed via ghcup, which is now 0.1.17.1.
It used to work until a couple of days ago. Completely uninstalling (and removing the directories of) Cabal and both GHC's did not help.

Removing custom config and leaving the builds/installs to be static works, but it's not an acceptable workaround because of hugely increased consumption of disk space.

My "desired" ~/.cabal/config: cabal-config.txt

Note: there's a problem with jobs: $ncpus in the ~/.cabal/config - it simply does no work on MacOS, as $ncpus value is nothing. Turned out false alarm for $ncpus.

[Mikolaj]

Thank you for the report. Do you mean ~/.cabal/config contains nothing? Or blank lines?

[gbaz]

I think this is due to a change in hashing that affects the store.

C.f. https://github.com/haskell/cabal/blob/3.6/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L234-L240

I'm surprised that wiping the store didn't solve this. 🤔

[mouse07410]

Do you mean ~/.cabal/config contains nothing? Or blank lines?

No, I created it with cabal user-config init.

Now I'm trying to bring it to the "desired" level step by step. I've added shared: True and exactable-dynamic: True, and several packages from Hackage got installed successfully:

$ cabal install shelltestrunner
Resolving dependencies...
Build profile: -w ghc-9.0.1 -O1
In order, the following will be built (use -v for more details):
 - Diff-0.4.0 (lib) (requires download & build)
 - HUnit-1.6.2.0 (lib) (requires download & build)
 - filemanip-0.3.6.3 (lib:filemanip) (requires download & build)
 - happy-1.20.0 (exe:happy) (requires build)
 - haskell-lexer-1.1 (lib:haskell-lexer) (requires download & build)
 - hostname-1.0 (lib:hostname) (requires download & build)
 - regex-tdfa-1.3.1.1 (lib) (requires download & build)
 - xml-1.3.14 (lib:xml) (requires download & build)
 - extensible-exceptions-0.1.1.4 (lib:extensible-exceptions) (requires download & build)
 - pretty-show-1.10 (lib) (requires download & build)
 - test-framework-0.8.2.0 (lib) (requires download & build)
 - test-framework-hunit-0.3.0.2 (lib:test-framework-hunit) (requires download & build)
 - shelltestrunner-1.9 (exe:shelltest) (requires download & build)
Downloading  haskell-lexer-1.1
Starting     happy-1.20.0 (exe:happy)
Building     happy-1.20.0 (exe:happy)
 .  .  .  .  .
Building     shelltestrunner-1.9 (all, legacy fallback)
Installing   shelltestrunner-1.9 (all, legacy fallback)
Completed    shelltestrunner-1.9 (all, legacy fallback)
Symlinking 'shelltest' to '/Users/ur20980/.cabal/bin/shelltest'

BTW, to save time and simplify my life when I need to (re-)install multiple packages from Hackage, I tend to specify them together in the install command, like

cabal install shelltestrunner summoner

Are there any problems with doing that? Should (independent) packages be specified just one per install command, like

cabal install shelltestrunner
cabal install summoner

?

I'm surprised that wiping the store didn't solve this

I'm greatly surprised by this - in my prior experience, wiping the store always resolved this kind of problems.

[gbaz]

Installing them all together on one line should be fine as far as I know.

[Mikolaj]

@mouse07410: thank you for the additional details. I was asking, because you original description has "When ~/.cabal/config contains" and then some empty lines and I wonder if that' means something or is a typo.

[Mikolaj]

[edited, removed; never mind me, a thinko]

[fgaz]

IIRC installing them together will try to share common dependencies, so with many packages you might not get a build plan, or you might get older packages

[jneira]

@mouse07410 only to be sure it is or is not a regression, the error is not reproduced with cabal-3.4.0.0 (it can be installed with ghcup)?

[mouse07410]

I'm not sure what to tell you - I was unable to build shared, so I disabled those options. Cabal store on that machine was empty at the time - I wiped everything out and started a-fresh.

After successfully installing a few static packages, I gradually re-endangered shared/dynamic. And now it's back to working - I'm building dynamic executables and shared libraries with Cabal-3.6.0.0.

Perhaps I should close this ticket, and reopen if I experience this again...

[jneira]

Thanks for the update, i've labeled with need repro i suppose we could let it opened some time just in case

[georgefst]

I've hit this same assertion after adding documentation: True to my ~/.cabal/config.

Happens with every project I try to build.

Setting locally with cabal configure --enable-doc works fine.

[Mikolaj]

@georgefst: thank you for the info. Are you still getting this? Can you reproduce after you wipe out your setup (~/.cabal mostly)?

[Mikolaj]

This may be related to #6006.

[Mikolaj]

@georgefst: hi! Could you try again? Was that with a local custom build with assertions enabled or a stock cabal binary?

[georgefst]

That will have been with stock 3.6 from GHCup. But I've just checked and also happens with the 3.9 I've been using lately, built from HEAD a few weeks ago.

[gbaz]

I think we have a real bug with all those assertions -- perhaps, when the global cabal config has these settings they don't make their way into the hash of the shared config. Definitely worth tracking down! That said, I'm very confused why people using stock ghcup cabals are hitting assertion failures at all -- shouldn't we be producing executables for distribution with all assertions turned off?

[georgefst]

That said, I'm very confused why people using stock ghcup cabals are hitting assertion failures at all -- shouldn't we be producing executables for distribution with all assertions turned off?

Apologies, it seems I may have misremembered here, as I can't now reproduce with stock 3.6.