On Wed, Nov 28, 2012 at 01:34:22PM +0000, Ganesh Sittampalam wrote:
On 28/11/2012 13:13, Ian Lynagh wrote:
More generally, if you can implement the "half a plan" you mentioned elsewhere in the thread for quickly building both static and dynamic ways, then the combination of the ABI and performance issues mean that I'm marginally in favour of keeping static linking as the default for executables on all platforms, but building the dynamic libraries for ghci.
That would solve the "installing libraries takes twice as long" problem, but not the "ghci can't load modules compiled with ghc -c" problem.
Can't ghc -c also produce both static and dynamic objects?
That's true, it could. Simon will point out that build systems will need updating if we start generating more/different files, but perhaps the pain would be worthwhile. I've been thinking about how to actually implement the half-plan. How about this? (don't worry about the names I've used for things for now): * Add a new way, "dynstatic". Compiling Foo this way makes Foo.ds_hi Foo.ds_s_o -- static Foo.ds_d_o -- dynamic and by default links statically. There's a flag to make it link dynamically instead. * When compiling things the dynstatic way, all dependencies must be compiled the dynstatic way * When compiling things the static way, dependencies can be compiled either the static or the dynstatic way * When compiling things the dynamic way, dependencies can be compiled either the dynamic or the dynstatic way * Cabal compiles dynstatic by default * ghc compiles dynstatic (linking statically) by default * ghci uses dynamic libraries on all platforms * If we are worried about performance of the compiler, then ship ghc as a static binary and ghci as a separate dynamic binary. The size of the two combined is only 2-3% larger than just the static binary. Thanks Ian