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 <ezy...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs