
Magnus Therning wrote:
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow
wrote: [..] Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later.
I have a really hard time following this. Are you seriously saying that GHC is inlining code from modules _and_ link dynamically at the same time. That seems like a remarkably strange thing to do, or maybe I'm just missing something.
That's exactly what would happen, if we shipped dynamic linking support with GHC as it stands. It's just a linking mechanism, an alternative to static linking, and has no impact on the amount or nature of inter-module optimisation that GHC does.
My understanding from another thread on here was that dynamic linking isn't working reliably, not even on Windows, where it once was supported. It has never worked on any other platform.
The fundamental mechanisms are working on {x86, x86-64, PPC, PPC64} / {Linux, OS X, Windows} and possibly other OSs. However right now you need a few small patches to the source tree to get it to build. Most of the unresolved issues are around how to construct binary installs, and how executables will find their libraries when the run (e.g. if you install GHC privately in your home directory). Cheers, Simon