#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