[GHC] #11118: Very hard to load previously compiled .o files in ghci

[GHC]

#11118: Very hard to load previously compiled .o files in ghci
-------------------------------------+-------------------------------------
        Reporter:  duncan            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by duncan:

Old description:

> It's extremely hard to get ghci to load .o files created previously. The
> upshot is that cabal repl never loads previous .o files. It did used to
> be also to with older ghc versions. There is currently nothing sensible
> cabal can do about this except to build things twice (which isn't
> sensible).
>
> When one compiles modules using -static -dynamic-too, then ghci will not
> load those .o files, even if one specifies the appropriate -dynosuf
> -dynhisuf.
>
> One way to get ghci to load the .o files is if one does not build the
> static .o files at all, and only builds with -dynamic. This means the
> main .o files are the dynamic ones.
>
> It's possible to do this and keep the sets of files separate, by using
> -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for
> --interactive mode.
>
> However it's then impossible to use the -dynamic-too mode, which we want
> since it saves time. In this mode, although ghc does indeed generate
> dyn_o and dyn_hi files, ghci will not load these, even if one specifies
> -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]".
>
> So it looks like the problem is that the -static -dynamic-too information
> gets saved into the generated dyn_hi files. The info that should be saved
> probably should be as if they were generated with -dynamic only.

New description:

 It's extremely hard to get ghci to load .o files created previously. The
 upshot is that cabal repl never loads previous .o files. It did used to be
 able to with older ghc versions. There is currently nothing sensible cabal
 can do about this except to build things twice (which isn't sensible).

 When one compiles modules using -static -dynamic-too, then ghci will not
 load those .o files, even if one specifies the appropriate -dynosuf
 -dynhisuf.

 One way to get ghci to load the .o files is if one does not build the
 static .o files at all, and only builds with -dynamic. This means the main
 .o files are the dynamic ones.

 It's possible to do this and keep the sets of files separate, by using
 -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for
 --interactive mode.

 However it's then impossible to use the -dynamic-too mode, which we want
 since it saves time. In this mode, although ghc does indeed generate dyn_o
 and dyn_hi files, ghci will not load these, even if one specifies -osuf
 dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]".

 So it looks like the problem is that the -static -dynamic-too information
 gets saved into the generated dyn_hi files. The info that should be saved
 probably should be as if they were generated with -dynamic only.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11118#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler