#9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description:
In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further.
{{{ module Foo where import Text.ParserCombinators.Parsec }}}
Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`.
My installed Parsec library seems to be working correctly. I can link and run `main = parseTest (char 'a') "a"` in both `-dynamic` and `-static` modes, and I can also use Parsec from GHCi.
GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3.
New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don’t always produce desirable results. When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don’t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. Of the two cases described above, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but causes problems when it's used. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9176#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler