Cabal: build failure for cabal 2.1 with cabal 2.0

[cartazio]

Summary (from @hvr's comment): This is actually a GHC bug. We could try to workaround this in new-build though; all we need to do is to delete e.g. the .o files for which the .dyn* files are missing or out of date before invoking ghc -dynamic-too --make.

---

3:15:57 ~/D/r/cabal-2.0-install-rc (master|✔) $ cabal install ./Cabal ./cabal-install --program-suffix=2.1
Resolving dependencies...
In order, the following will be installed:
Cabal-2.1.0.0 (via: cabal-install-2.1.0.0 cabal-install-2.1.0.0
hackage-security-0.5.2.2) (new version)
hackage-security-0.5.2.2 (via: cabal-install-2.1.0.0) (reinstall) (changes:
Cabal-2.0.0.2 removed)
cabal-install-2.1.0.0 (new package)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring Cabal-2.1.0.0...
Building Cabal-2.1.0.0...
Failed to install Cabal-2.1.0.0
Build log ( /Users/carter/.cabal/logs/ghc-8.2.1/Cabal-2.1.0.0-8dmO4pupuJQ40XZZ67hKid.log ):
cabal: Entering directory './Cabal'
Configuring Cabal-2.1.0.0...
Preprocessing library for Cabal-2.1.0.0..
Building library for Cabal-2.1.0.0..
gcc-7: error: dist/build/Distribution/Simple/CCompiler.dyn_o: No such file or directory
`gcc' failed in phase `Linker'. (Exit code: 1)
cabal: Leaving directory './Cabal'
cabal: Error: some packages failed to install:
Cabal-2.1.0.0-8dmO4pupuJQ40XZZ67hKid failed during the building phase. The
exception was:
ExitFailure 1
cabal-install-2.1.0.0-2MTVJEMTXQr6xOpZFe4JiL depends on cabal-install-2.1.0.0
which failed to install.
hackage-security-0.5.2.2-DQYPdO72PWA799IGz0LWXZ depends on
hackage-security-0.5.2.2 which failed to install.

[hvr]

One thing I've noticed is that if for any reason (usually when GHC gets interrupted via ctrl-c or other abnormal terminations) either of the *.dyn_{hi,o} files go missing, then either GHC fails to detect they're missing. A simple example which exhibits this is running

$ ghc --make M1 M2 M3
[1 of 3] Compiling M3               ( M3.hs, M3.o )
[2 of 3] Compiling M2               ( M2.hs, M2.o )
[3 of 3] Compiling M1               ( M1.hs, M1.o )

which genreates only .o and .hi files, followed by

$ ghc -dynamic-too --make M1 M2 M3

Then the 2nd invocation of ghc fails to detect that the .dyn_* files are missing, and consequently thinks there's nothing to be done.

TLDLR, this is actually a GHC bug. We could try to workaround this in new-build though; all we need to do is to delete e.g. the .o files for which the .dyn* files are missing or out of date before invoking ghc -dynamic-too --make.

[ezyang]

cabal doesn't (currently) know about what output files GHC emits per source codes, so this would a bit of logic to add. (Mind you, it's good logic to have, but it's a yak to shave.)

[ttuegel]

One thing I've noticed is that if for any reason (usually when GHC gets interrupted via ctrl-c or other abnormal terminations) either of the *.dyn_{hi,o} files go missing, then either GHC fails to detect they're missing.

This is ugly. The most important thing we can do on our side is educate our users that it is _never_ safe to interrupt cabal-install, and to obliterate dist/ or dist-newstyle/ if this occurs. It reminds me of when we had to tell users to obliterate $HOME/.cabal if there was a dependency-hell problem.

cabal doesn't (currently) know about what output files GHC emits per source codes, so this would a bit of logic to add

Logic that isn't even right in GHC itself!

TLDLR, this is actually a GHC bug. We could try to workaround this in new-build though

At what point do we stop trying to work around GHC's bugs? After awhile, it would just make more sense to implement a compiler in Cabal. 😃

Aside from documenting the bug, I think we should close this issue WONTFIX and deal with it in GHC.

[ezyang]

Yes, we need to fix GHC to emit the "thing it actually checks for recompilation" after "all the other auxiliary files" and not before.

[hvr]

The most important thing we can do on our side is educate our users that it is never safe to interrupt cabal-install

From a UX POV that's a problem though IMO. I frequently interrupt cabal myself (even from within Emacs), when I notice something in it's output that renders the rest of the compilation (which could easily drag on for several minutes otherwise) useless while developing. I think it's a common expectation from users, i.e. that they can interrupt their build process, rather than have to wait it out to its bitter end. I'd be fine though if interrupting results in Cabal results in automatically cleaning the components it was working on while getting interrupted. Or even better, since we cannot guarantee cabal's cleanup-actions to be executed: keep track on the filesystem whether work on a component has been terminated "normally" (i.e. not via ctrl-c, or the GHC process exiting with a weird exit-code), and the next cabal invocation will delete/wipe a component's artifacts unless a normal termination has been recorded.

[cartazio]

I agree with hvr and ttuegel. We don’t even expose a clean / mark the same
config as new so regenerate everything interface ... AND this is an issue
for new and power users both!

On Wed, Oct 25, 2017 at 1:56 AM Herbert Valerio Riedel <
[email protected]> wrote:

The most important thing we can do on our side is educate our users that
it is never safe to interrupt cabal-install

From a UX POV that's a problem though IMO. I frequently interrupt cabal
myself (even from within Emacs), when I notice something in it's output
that renders the rest of the compilation (which could easily drag on for
several minutes otherwise) useless while developing. I think it's a common
expectation from users, i.e. that they can interrupt their build process,
rather than have to wait it out to its bitter end. I'd be fine though if
interrupting results in Cabal results in automatically cleaning the
components it was working on while getting interrupted. Or even better,
since we cannot guarantee cabal's cleanup-actions to be executed: keep
track on the filesystem whether work on a component has been terminated
"normally" (i.e. not via ctrl-c, or the GHC process exiting with a weird
exit-code), and the next cabal invocation will delete/wipe a component's
artifacts unless a normal termination has been recorded.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/haskell/cabal/issues/4635#issuecomment-339222914, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAQwoBJXUasCibHrXHXVMHGvgC5Fd_Vks5svs2AgaJpZM4Ollhd
.

[ttuegel]

Or even better, since we cannot guarantee cabal's cleanup-actions to be executed: keep track on the filesystem whether work on a component has been terminated "normally" (i.e. not via ctrl-c, or the GHC process exiting with a weird exit-code), and the next cabal invocation will delete/wipe a component's artifacts unless a normal termination has been recorded.

I can get behind this solution!

• It does not require trying to replicate or work around internal details of GHC.
• It applies equally to any compiler. (Hypothetically.)
• It eliminates other sources of inconsistency, too. (Power loss during build? Most filesystems guarantee filesystem integrity, not data integrity. Yes, yes, we could all be using ZFS. Don't @ me.)