ghc api and .o files

JP Moresmau jpmoresmau at
Fri Sep 14 07:58:46 CEST 2012

I also would like to see an API change document when a new version of
GHC is released! Now a few libraries use the API, so I don't know if
it can be considered "internal".


On Fri, Sep 14, 2012 at 7:31 AM, Evan Laforge <qdunkan at> wrote:
> 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!
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

JP Moresmau

More information about the Glasgow-haskell-users mailing list