Using GHC API to compile Haskell file
Edward Z. Yang
ezyang at mit.edu
Sun Aug 23 23:00:35 UTC 2015
The problem is that the default code is trying to build a dynamically
linked executable, but the Windows distributions don't come with dlls
by default.
Why doesn't the GHC API code pick this up? Based on snooping
ghc/Main.hs, it's probably because you need to call parseDynamicFlags*
which will call updateWays which will turn off -dynamic-too if the
platform doesn't support it.
GHC bug? Absolutely! Please file a ticket.
Edward
Excerpts from Neil Mitchell's message of 2015-08-23 05:43:28 -0700:
> Hi,
>
> Is this the right place for GHC API queries? If not, is there anywhere better?
>
> I want to compile a Haskell module, much like `ghc --make` or `ghc -c`
> does. The sample code on the Haskell wiki
> (https://wiki.haskell.org/GHC/As_a_library#A_Simple_Example),
> StackOverflow (http://stackoverflow.com/a/5631338/160673) and in GHC
> API slides (http://sneezy.cs.nott.ac.uk/fplunch/weblog/wp-content/uploads/2008/12/ghc-api-slidesnotes.pdf)
> says:
>
> import GHC
> import GHC.Paths ( libdir )
> import DynFlags
>
> main =
> defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
> runGhc (Just libdir) $ do
> dflags <- getSessionDynFlags
> setSessionDynFlags dflags
> target <- guessTarget "Test.hs" Nothing
> setTargets [target]
> load LoadAllTargets
>
> However, given a `Test.hs` file with the contents `main = print 1`, I
> get the error:
>
> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
> cannot find -lHSbase-4.7.0.1-ghc7.8.3
> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
> cannot find -lHSinteger-gmp-0.5.1.0-ghc7.8.3
> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
> cannot find -lHSghc-prim-0.3.1.0-ghc7.8.3
> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
> cannot find -lHSrts-ghc7.8.3
> C:/Program Files (x86)/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/ld.exe:
> cannot find -lffi-6
> collect2: ld returned 1 exit status
>
> Has the recipe changed?
>
> By turning up the verbosity, I was able to compare the command line
> passed to the linker. The failing GHC API call contains:
>
> "-lHSbase-4.7.0.1-ghc7.8.3" "-lHSinteger-gmp-0.5.1.0-ghc7.8.3"
> "-lHSghc-prim-0.3.1.0-ghc7.8.3" "-lHSrts-ghc7.8.3" "-lffi-6"
>
> While the succeeding ghc --make contains:
>
> "-lHSbase-4.7.0.1" "-lHSinteger-gmp-0.5.1.0"
> "-lHSghc-prim-0.3.1.0" "-lHSrts" "-lCffi-6"
>
> Should I be getting DynFlags differently to influence those link variables?
>
> Thanks, Neil
More information about the ghc-devs
mailing list