GHC API, GHCi, profiling, shared objects

[Matthew Pickering]

OK, so by accident I have stumbled across some documentation for the
remote interpreter which I think claims to solve some of these issues.

https://gitlab.haskell.org/ghc/ghc/wikis/remote-ghci
https://simonmar.github.io/posts/2016-02-12-Stack-traces-in-GHCi.html

Simon in his blog post explains that there are some advantages to the
external interpreter.

1. The interpreter and compiler can be run using separate runtimes.

In the context of the GHCi API I believe this means that the GHC API
program can be compiled the profiling way BUT the interpreted code can
be compiled the normal way, which is the opposite to the use case
suggested in the blog post.

2. The decision about whether to use the dynamic linker is separated
from whether the executable is dynamically linked.

We have discovered that compiling the executable with -dynamic causes
the interpreted code to use the system dynamic linker as well which is
significantly more performant.

Therefore it seems like a sensible plan to enable
`-fexternal-interpreter` in the GHC API application.

On Sat, Apr 27, 2019 at 12:37 PM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> Hi,
>
> If I write a program using the GHC API then the resulting executable
> is sensitive to the version of GHC which I used to build the program.
>
> For example, if I build a version of GHC which has profiling enabled
> (prof flavour) then building my application (static linking) with this
> version means that I can only load packages which were also built with
> profiling enabled. This happens in particular when you load a module
> which uses TemplateHaskell which causes all the dependencies to be
> loaded.
>
> If the so isn't built with profiling then you get errors such as
>
> ```
> <command line>: can't load .so/.DLL for:
> libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib
> (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5):
> image not found)
> ```
>
> This seemed to somewhat make sense to me because compiling
> with/without profiling changes
> the heap representation but then I considered whether this also
> happens in GHCi and I concluded that it didn't.
>
> In particular, it seems to me that
>
> 1. GHCi is not built by a profiled version of GHC and is still a "GHC
> API application"
> 2. There is no problem loading profiled packages into GHCi despite this fact?
>
> 1. Does GHCi do something special to mitigate against these kinds of failures?
> 2. Is this a difference between staticly and dynamically linking the
> application executable (`ghc` in the case for ghci). ?
>
> Hopefully someone familiar with the implementation of the linker will
> be able to clear this up.
>
> Cheers,
>
> Matt