#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