unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Federico Beffa <beffa@ieee.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: For a slimmer GHC
Date: Mon, 2 Nov 2015 17:01:28 +0100	[thread overview]
Message-ID: <CAKrPhPNSmYvxMWOX1C2_=CYPjvKjh2jij8z8Y93_MdJjnma-1w@mail.gmail.com> (raw)
In-Reply-To: <87wpu0ij8l.fsf@gnu.org>

On Mon, Nov 2, 2015 at 3:11 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> ludo@gnu.org (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

  reply	other threads:[~2015-11-02 16:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 11:23 For a slimmer GHC Federico Beffa
2015-11-02 14:11 ` Ludovic Courtès
2015-11-02 16:01   ` Federico Beffa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-10-29 19:17 Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKrPhPNSmYvxMWOX1C2_=CYPjvKjh2jij8z8Y93_MdJjnma-1w@mail.gmail.com' \
    --to=beffa@ieee.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).