GHC does not relink if we link against a new library with old timestamp
Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance-bug/
myexe is an executable that depends on mylib, whose myfun = putStrLn "output 1".
If we install mylib, compile myexe, then change mylib's code to myfun = putStrLn "output 2", re-install it, and then compile myexe, then GHC does not notice that the library code changed.
It avoids re-linking myexe, with the result that the program prints output 1 when you told it to compile against code that prints output 2.
Note that I had to use NOINLINE myfun to trigger the bug, since otherwise myfun's code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile).
With the NOINLINE, the package IDs of the two different versions of myfun are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right?
How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture |