Dynamic libraries by default and GHC 7.8

[Ganesh Sittampalam]

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

Cheers,

Ganesh