ghc api and .o files
jpmoresmau at gmail.com
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 gmail.com> 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.
> 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.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users