#3799: undefined symbols and undefined references possibly related to template
haskell
---------------------------------+------------------------------------------
Reporter: JeremyShaw | Owner:
Type: bug | Status: closed
Priority: normal | Milestone: 6.12.2
Component: Compiler | Version: 6.13
Resolution: invalid | Keywords: undefined symbols
references template haskell
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Compile-time crash |
---------------------------------+------------------------------------------
Comment(by simonmar):
It may be mitigated by this recent patch:
{{{
Tue Jan 12 14:58:53 PST 2010 Simon Marlow <[email protected]>
* Do some recompilation avoidance in GHC.loadModule
GHC.loadModule compiles a module after it has been parsed and
typechecked explicity. If we are compiling to object code and there is
a valid object file already on disk, then we can skip the compilation
step. This is useful in Haddock, when processing a package that uses
Template Haskell and hence needs actual compilation, and the package
has already been compiled.
As usual, the recomp avoidance can be disabled with -fforce-recomp.
M ./compiler/main/GHC.hs -7 +17
M ./compiler/main/HscMain.lhs +17
}}}
because this should mean that `cabal haddock` won't do any actual
recompilation if the package is already built. It's not a robust fix,
since if you modify a source file then `cabal haddock` will still do some
compilation without updating the `HSsyb-with-class-0.6.1.o` file.
The sledgehammer fix in Cabal (use a different `-odir` when haddocking)
will avoid the problem, but at the cost of forcing `cabal haddock` to
compile everything. I suggest a better fix might be for `cabal haddock`
to invoke `cabal build` before running Haddock, to ensure that the object
files are up to date.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3799#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
