GHC API, GHCi, profiling, shared objects

[Matthew Pickering]

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