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