#9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => closed * priority: high => normal * version: 7.10.2 => 7.6.3 * resolution: => fixed Comment: Okay, that's helpful and different from how my package was built. I managed to reproduce the error you saw by building an archive with an undefined symbol reference and specifying it with `extra-libraries:` and `extra-lib-dirs:` in `hs-opencv-binding.cabal`. (Of course, it's not a bug that GHC fails when there really is an undefined symbol!) It turns out that the GHC runtime linker is still used in the following situation: When loading a package into GHCi, the last step is to load libraries specified in the `extra-libraries:` field of the package registration. For each such library, GHCi will first try to find a matching shared library in the library path, then try to find a matching static library in the library path, then ask gcc where to find a shared library, and if all those fail, assume that `dlopen` will know where to find the shared library. (`compiler/ghci/Linker.hs`, function `locateLib`.) It is that second case that you are apparently in (I guess you only built OpenCV as a static library) and in that case the static library is loaded by the GHC runtime linker (in `linkPackage` in the same file). That is all fine, except that the GHC runtime linker apparently doesn't understand this `"u"` symbol type. But that is almost certainly unrelated to the original ticket here, so I reset the ticket status back to its previous state. I recommend that you simply use dynamic OpenCV libraries, if at all possible. If not, you will apparently need support for this `"u"` symbol type in the GHCi runtime linker. I'm not sure I understand exactly what the semantics of this symbol type are supposed to be, but it looks fairly straightforward to implement. However, that would obviously require a patch to GHC... so it would probably be easier for you just to use dynamic OpenCV libraries, and avoid the hairiness of the GHC runtime linker. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9010#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler