GHCi fails to recompile when dependencies change
If there's a chain of dependency such as D -> A -> B, when we introduce a new module C such that B -> C and keep D & A the same, GHCi doesn't recompile D. This is incorrect since the mi_deps
field of D's ModIface
should have changed, and thus causes a linker error. This is a small repro case where if we start with v1.patch, :load D.hs
and then change to v2.patch, :reload
and run D.main, we would have a linker error.
This is the console output on my machine
[lolotp@lolotp-fedora-R90RRK8K fbghc]$ sudo docker run -it -v $(pwd):/fbghc haskell:8.6.3 /bin/bash
root@f283d88bebfd:/fbghc# ghci
GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help
Prelude> :!git checkout ok -- This corresponds to v1.patch
Switched to branch 'ok'
Prelude> :l D.hs
[1 of 3] Compiling B ( B.hs, interpreted )
[2 of 3] Compiling A ( A.hs, interpreted )
[3 of 3] Compiling D ( D.hs, interpreted )
Ok, three modules loaded.
*D> :!git checkout bad -- This corresponds to v2.patch
Switched to branch 'bad'
*D> :r
[1 of 4] Compiling C ( C.hs, interpreted )
[2 of 4] Compiling B ( B.hs, interpreted )
[3 of 4] Compiling A ( A.hs, interpreted ) [B changed]
Ok, four modules loaded.
*D> main
ghc: ^^ Could not load 'C_idd_closure', dependency unresolved. See top entry above.
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
C_idd_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
*D>