Using GHC API to compile Haskell file

[Edward Z. Yang]

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