ghc api and .o files

[Evan Laforge]

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!