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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
