Dynamic libraries by default and GHC 7.8
ganesh at earth.li
Wed Nov 28 14:34:22 CET 2012
On 28/11/2012 13:13, Ian Lynagh wrote:
>> My general feeling about Windows is that it's ok for the end result to
>> be a little annoying, because Windows DLLs *are* annoying and it's
>> nothing to do with GHC.
>> In particular I think in practice most Windows developers will have
>> admin rights and could live with the ghc installation and cabal install
>> having to be done as elevated operations. Where they weren't done with
>> admin rights, then ghc -o could warn the user that the DLLs need to be
>> copied locally (or even copy them itself and tell the user it happened).
> Personally, I would prefer the "C stub" option to that.
I think that one would be ok too, but I somewhat prefer SxS simply
because of the long-term costs of being non-standard.
>> 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? I guess only
one of the two could be called sourcefile.o
More information about the Glasgow-haskell-users