Indeed it was, I initially thought it wasn't because I wasn't using flags for either, but then I remember ghci also picks up flags from ~/.ghci. Turns out I was using -fno-monomorphism-restriction because that's convenient for ghci, but not compiling with that.
I guess in the case where an extension changes the meaning of existing code it should be included in the fingerprint and make the .o not load. But my impression is that most ExtensionFlags let compile code that wouldn't compile without the flag. So shouldn't it be safe to exclude them from the fingerprint?
Either way, it's a bit confusing when .ghci is slipping in flags that are handy for testing, because there's nothing that tells you *why* ghci won't load a particular .o file.
After some fiddling, I think that -osuf should probably be omitted from the fingerprint. I use ghc -c -o x/y/Z.hs.o. Since I set the output directly, I don't use -osuf. But since ghci needs to be able to find the .o files, I need to pass it -osuf. The result is that I need to pass ghc -osuf when compiling to get ghci to load the .o files, even though it doesn't make any difference to ghc -c, which is a somewhat confusing requirement.
In fact, since -osuf as well as the -outputdir flags affect the location of the output files, I'd think they wouldn't need to be in the fingerprint either. They affect the location of the files, not the contents. If you found the files it means you already figured out what you needed to figure out, it shouldn't matter *how* you found the files.
And doesn't the same go for -i? Isn't it valid to start ghci from a different directory and it should work as long as it's able to find the files to load?
Further updates: this has continued to cause problems for me, and now I'm wondering if the CPP flags such as -D shouldn't be omitted from the fingerprint too. Here's the rationale: I use CPP in a few places to enable or disable some expensive features. My build system knows which files depend on which defines and hence which files to rebuild. However, ghci now has no way of loading all the .o files, since the ones that don't depend on the -D flag were probably not compiled with it and those that do were. This also plays havoc with the 'hint' library, which is a wrapper around the GHC API. I can't get it to load any .o files and it's hard to debug because it doesn't tell you why it's not loading them. In addition, ghc --make used to figure out which files depended on the changed CPP flags and recompile only those. Now it unconditionally recompiles everything. I always assumed it was because GHC ran CPP on the files before the recompilation checker. If that's the case, do the CPP flags need to be included in the fingerprint at al? It seems like they're already taken into account by the time the fingerprints are calculated. I reviewed http://hackage.haskell.org/trac/ghc/ticket/437 and I noticed there was some question about which flags should be included. Including the language flags and -main-is since that was the original motivation (but only for the module it applies to, of course) makes sense, but I feel like the rest should be omitted.