[GHC] #9176: GHC not generating dyn_hi files
GHC
ghc-devs at haskell.org
Fri Dec 25 21:17:02 UTC 2015
#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: Unknown/Multiple | Architecture: x86_64
| (amd64)
Type of failure: Other | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by ezyang):
So, let's see if we can get this straight:
1. In principle, it would be better if we didn't have any `dyn_hi` files.
We should only have an `hi` file which everyone uses for typechecking.
Because `-dynamic` does not affect type-checking/core optimization (it
only affects the backend), any `dyn_hi` file you generate SHOULD be the
same as `hi`. I'm pretty sure there isn't anything that is affected by
this, and if there IS something we should kill it.
2. In practice, if `-dynamic-too` does not work (as claimed on Windows),
you have to run the compiler twice (once with `-dynamic` and once without)
to actually get both dynamic and normal object files. Now, GHC is
nondeterministic, so we're not guaranteed to get the same interface each
time. That's trouble. Additionally, if you don't call GHC with exactly the
same flags as the first time, you will end up with different interface
files easily.
The moral of the story is that you should not be allowed compile static
objects, and THEN compile dynamic objects in a separate GHC invocation.
Then the nondeterminism problem goes away and we can kill `dyn_hi` files
with fire.
It seems to me that `-dynamic-too`, even for platforms which "don't
support it". I am not exactly sure how `-dynamic-too` is implemented, but
in the worst case scenario it should be sufficient to just run the entire
backend pipeline twice.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9176#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list