#8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): So here are three approaches that come to mind for the original Template Haskell issue. 1. When dynamically loading module M from package P, just link together all the dependencies of M in package P, regardless of whether they have been loaded already, and hope that loading two copies of a dependency won't cause any problems. Unclear whether the latter is the case. 2. After building and loading the shared library of dependencies and running Template Haskell for a module, unload the shared library. (Or, lazily unload it only when we need to load more modules that have intra- package dependencies on modules we have loaded already.) I don't know how difficult this is, but I understand that unloading shared libraries is supposed to basically work, so perhaps it's not hard. 3. Build a separate "flavor" of object file `.really_dyn_o` that uses dynamic references even to symbols in the same package, so we can freely dynamically load individual modules. These are needed only while building a package that uses Template Haskell; once the package is completely built they can be thrown away. This is the most obviously correct option IMO, but it might impose a pretty high build time cost. I think option 2 is best, unless it turns out to be a lot harder than I anticipate, with option 3 my second choice. There's a closely related issue in ghci with incrementally loading modules in the "main" (i.e., no) package, which is what the test case I attached actually demonstrates. In this setting, unloading old modules so that we can reload them linked against new ones seems less reasonable, since we might be resetting global state I guess. So here I think option 3 is best. It would be very easy to implement: simply disallow static linking to any symbol in the "main" package. (Is there a good reason to build `.dyn_o` files for an executable in the first place?) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8696#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler