[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 simonmar):

 @rwbarton diagnosed it correctly.  The problem is that

  * when we compile objects for dynamic linking, references to symbols in
 the same package are static references, resolved when we link the dynamic
 library together.

  * But in GHCi, we are not loading all the modules together, we're loading
 only the modules we need to satisfy the dependencies of the current
 expression, linked together as a shared library.  If we need more modules
 later, we link those as a separate shared library, which breaks the
 assumption that all the objects of a package are linked into the same
 shared library.  In the test case. T8696A is loaded first, then when we
 try to load T8696B we can't resolve the reference to T8696A because it is
 in a different shared library.

 We can link *all* the objects together, regardless of what we actually
 depend on, and load the whole shared library (and all the package
 dependencies).  The problem with this is that when compiling multiple
 modules with TH we'll end up loading O(n^2) the number of modules.
 Unloading doesn't work  with dynamic linking.

 Sigh. I hate dynamic linking.  This all used to work properly before.

 I've run out of time for this today, but there isn't an obviously right
 solution so it needs a bit more thought anyway.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8696#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler