ghc api and .o files

JP Moresmau 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".

JP

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.
> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
JP Moresmau
http://jpmoresmau.blogspot.com/



More information about the Glasgow-haskell-users mailing list