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: email@example.com *D>