Re: Using GHC API to compile Haskell file

24 Aug 2015

      Thanks Edward, that fixed the issue with GHC 7.8.3. While trying to
replicate with 7.10.2 to submit a bug report, I got a different error,
even with your fix included:

C:\Users\NDMIT_~1\AppData\Local\Temp\ghc2428_1\ghc_4.o:ghc_3.c:(.text+0x55):
undefined reference to `ZCMain_main_closure'

Doing another diff of the command lines, I see ghc --make includes
"Test.o" on the Link line, but the API doesn't.

Thanks, Neil

On Mon, Aug 24, 2015 at 12:00 AM, Edward Z. Yang  wrote:
...
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-ap...)
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