[GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol'

[GHC]

#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