GHC (API?) question: GHC Core for Base libraries
Brandon Allbery
allbery.b at gmail.com
Tue Dec 4 04:10:23 UTC 2018
The problem here is that you're using a stage 1 build, and stage 1 lacks
support for the bytecode backend used by TH, plugins, ghci, etc. A base
build with a stage 2 compiler should work.
On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <william.hallahan at yale.edu>
wrote:
> Hi,
>
> I'm writing a program analyzer that operates on GHC Core. Currently, I'm
> using the GHC API to get Core from .hs files. I'd like to be able to run
> this analysis on the standard libraries that come with GHC, which requires
> getting those as Core.
>
> Unfortunately, the build process for these libraries is not entirely
> straightforward, and relies on a make script. I eventually came up with
> the plan of writing a GHC plugin, which, rather than performing any
> optimizations, would simply run the analysis, and then print the results
> out to a file. I was able to write the plugin successfully, and test it on
> several files that were *not* from the base library.
>
> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
> the make script would call the plugin. I ended up with the following:
>
> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
> -package hplugin -fplugin HPlugin.Plugin -v
>
> The two package databases are to get to (1) the GHC API and (2) the plugin
> ("hplugin") itself. With this I get an error message, which I have not
> been able to find a way to resolve:
>
> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O
> -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
> -ilibraries/ghc-prim/dist-install/build/autogen
> -Ilibraries/ghc-prim/dist-install/build
> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
> -optP-include
> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
> hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts
> -Wno-trustworthy-safe -Wno-deprecated-flags
> -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build
> -hidir libraries/ghc-prim/dist-install/build -stubdir
> libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c
> libraries/ghc-prim/./GHC/Types.hs -o
> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
> <command line>: not built for interactive use - can't load plugins
> (HPlugin.Plugin)
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
> make: *** [all] Error 2
>
> So I'm now wondering (an answer to either of these two questions would be
> helpful):
> (1) Is this a viable path? That is, is it possible to use a plugin when
> building Base? If so, does anyone know what I might be doing wrong/what
> could be causing this error message?
> (2) Is there some other better/easier way I could get Core representations
> of the standard libraries? I guess, in theory, it must be possible to
> compile the standard libraries with the GHC API, but I have no idea
> how/where to look to figure out how?
>
> Thanks,
> Bill
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
--
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181203/cf2f008a/attachment-0001.html>
More information about the ghc-devs
mailing list