#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:
== 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. This file is a copy of the other `User.hs`, just compiled differently.
== Problems ==
GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does not when compiling the third file.
When compiling a module, GHC should read the interfaces of any modules that it imports. However, when compiling the second file, GHC does not read the .dyn_hi files describing the imported dynamic modules, only the .hi files describing the normal modules.
The compiler does not treat mismatched module interfaces consistently in all situations, making it hard to find the root cause of errors.
I'm not sure what the correct behavior should be.
== 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.
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 importing from the package prevents dynamic-too compilation from working properly. == 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. This file is a copy of the other `User.hs`, just compiled differently. == Problems == GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does not when compiling the third file. When compiling a module, GHC should read the interfaces of any modules that it imports. However, when compiling the second file, GHC does not read the .dyn_hi file describing the imported dynamic module, only the .hi file describing the normal module. The compiler does not treat mismatched module interfaces consistently in all situations, making it hard to find the root cause of errors. I'm not sure what the correct behavior should be. == 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:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler