Using GHC API to compile Haskell file
Edward Z Yang
ezyang at mit.edu
Thu Sep 3 17:51:43 UTC 2015
Hello Neil,
Sorry about the delay; I hadn't gotten around to seeing if I could reproduce it. Here is a working copy of the program which appears to work with GHC 7.10.2 on 64-bit Windows:
module Main where
import GHC
import GHC.Paths ( libdir )
import DynFlags
import SysTools
main = do
defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
setSessionDynFlags (gopt_set dflags Opt_Static)
target <- guessTarget "Test.hs" Nothing
setTargets [target]
load LoadAllTargets
Here is how I tested it:
stack ghc -- -package ghc -package ghc-paths --make Main.hs
(after stack installing ghc-paths)
Did you mean the error occurred when you did set Opt_Static? I can’t reproduce your specific error in that case either.
Cheers,
Edward
Sent from Windows Mail
From: Neil Mitchell<mailto:ndmitchell at gmail.com>
Sent: Monday, August 24, 2015 12:42 AM
To: Edward Z Yang<mailto:ezyang at mit.edu>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
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 <ezyang at mit.edu> 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-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150903/7bf7d39c/attachment.html>
More information about the ghc-devs
mailing list