GHC does not relink if we link against a new library with old timestamp
|Reported by:||nh2||Owned by:|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||#10966||Differential Rev(s):|
Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance-bug/
myexe is an executable that depends on
myfun = putStrLn "output 1".
If we install
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
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).
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.
Change History (6)
comment:5 Changed 6 months ago by
|Summary:||GHC does not relink if a library's code changed → GHC does not relink if we link against a new library with old timestamp|