#5620: Dynamic linking and threading does not work on Windows
-------------------------------+--------------------------------------------
Reporter: Lennart | Owner: igloo
Type: bug | Status: new
Priority: high | Milestone: 7.4.2
Component: Runtime System | Version: 7.2.1
Keywords: | Os: Windows
Architecture: x86 | Failure: Runtime crash
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
-------------------------------+--------------------------------------------
Comment(by duncan):
So the general problem is explained here http://www.well-
typed.com/blog/30. That describes it in the context of ELF, but the
problem with PE/.dll is essentially the same. The mechanisms available to
solve it are different.
To summarise: the problem is that we want to be able to compile packages
as .dlls without yet committing to a particular flavour of RTS. We want to
be able to choose when we finally link our program if we'll use the
normal, threaded, debug, eventlog etc flavour. Each of these are ABI
compatible so it's ok. With static linking this works fine because we only
do one big link at the very end, including the RTS. With dynamic linking,
we need to link each .dll with its dependencies, including the RTS.
On ELF we currently have a hack that works (in the sense of not
segfaulting) but it's not nice or convenient. That hack works simply by
not linking package .so files against the RTS at all, leaving all the RTS
symbols dangling. Then only the final executable gets linked to the RTS.
That works on ELF because ELF allows dangling symbols. The same hack does
not work with PE/.dll because, sensibly, PE does not allow dangling
symbols in .dlls. So currently on Windows we link package .dlls to the
vanilla RTS but that mean if you link the main .exe to the threaded RTS
then we are linking to two RTS .dll files and boom!
So, what I think we need is a solution where all the RTS flavours that are
ABI compatible should share the same internal dll name, but they should
live in different sub-directories. All the package dlls should be linked
using an import library for the RTS. The import lib would be common
between all the RTS flavours (using an import lib would also resolve the
recursive symbol dependencies between the RTS and base libs).
The only question then is how does the final linked .exe find the right
RTS dll. That should use assemblies. Assemblies are a mechanism introduced
with XP that we should now make use of. Local assemblies let you stick a
bunch of dlls in a subdir, with a little xml manifest containing a GUID.
The exe is then linked with another xml manifest identifying the GUIDs of
the assemblies it needs. The Windows dynamic linker then uses these
manifests to find the dlls in the local subdirs. It's in many ways like
the ELF RPATH/RUNPATH mechanism, except that it is limited to local
subdirs where the exe lives rather than anywhere on the system.
More generally, all ghc packages built as dlls should use the assembly
mechanism.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5620#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
