I'm using the GHC api to run a little REPL for my app. This involves linking in some compiled C, and as long as it's in a library it's fine, I just pass -lwhatever to parseDynamicFlags and it's happy. However, I also have a plain .o file, and from poking at the ghci source, it looks like that works by consing onto v_Ld, which is not exported from StaticFlags. I was just about to go verify this, but it looks like it just changed! So maybe .o files can now be passed to parseStaticFlags? Or even better, parseDynamicFlags? However, it seems to have happened very recently, and 7.6.1 is still using the v_Ld global. Does this mean that there's no way to link in an arbitrary .o? I suppose I can work around it by packing the .o into a libx.a and then passing -lx. Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious. As an aside, I recently upgraded to 7.6.1 from 7.0.3 and the API changed in a numer of ways. Is there any documentation for those changes? I'm guessing not, since there's not much documentation for the API itself, except of course the code. I noticed that GHC.getWarnings disappeared, and seems to have been replaced with either printing directly to stderr or throwing an exception, e.g. HscTypes.handleFlagWarnings. Other than the expected hassles from depending on an internal API, 7.6.1 has been great so far, except of course hackage had to go down as soon as it was time to cabal install everything. thanks!