Re: For a slimmer GHC

[Federico Beffa]

On Mon, Nov 2, 2015 at 3:11 PM, Ludovic Courtès <address@hidden> wrote:
> Federico Beffa <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>
> [...]
>
>>> What about removing all the .a?  Would that be OK?
>>>
>>> On that topic I found
>>> <https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault> but it’s not
>>> clear to me whether this is relevant here.  At worst we can add a phase
>>> that removes these files.
>>
>> I do not know much about this topic, but I think that the discussion at
>> the link you provided is relevant, as probably is the one at
>>
>> https://ghc.haskell.org/trac/ghc/wiki/DynamicLinkingDebate
>>
>> My interpretation of the above discussions is that it is in principle OK
>> to remove statically linked libraries, but: (i) you loose the
>> possibility to create statically linked executables (the default; the
>> discussion here is about Haskell libraries, not system libraries), (ii)
>> dynamically linked executables are slower than statically linked ones
>> and (iii) it may create some build systems compatibility problems.
>
> (i) and (ii) apply to all the packages in Guix, not just Haskell
> packages: most of the time we provide only shared libraries, and PIC
> code includes a slight “performance penalty” (and possibly large memory
> savings if several processes use the library.)
>
> I’m not sure what (iii) means though?

I'm not sure either :-) It's one of the reasons listed in the
discussion at the above link. I'm just passing on the information.

>
>> Personally I would keep them as the above discussions give me the
>> impression that dynamic linking is not very mature in GHC. In any case,
>> if people feel strongly about removing static libraries, then I would at
>> least add an option to the build-system to easily re-enable their
>> creation.
>
> I think we could even simply move them to a different output, for those
> who really need them.

That would be ideal, but I'm not sure you can simply move them. The
location of a library must be listed in the binary library cache. I do
not know if you can have more entries for a single library. I guess
that would have to be investigated experimentally.

Regards,
Fede