GHC API, GHCi, profiling, shared objects
matthewtpickering at gmail.com
Sat Apr 27 11:37:12 UTC 2019
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
If the so isn't built with profiling then you get errors such as
<command line>: can't load .so/.DLL for:
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
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.
More information about the ghc-devs