GHC 6.8.2 as a library on Windows and GHCi
I while I ago I sent an email regarding hs-plugins not working on windows. I now tried to directly use GHC API, but I also failed. The following program (which might be buggy, I copy/pasted from various sources) import DynFlags import GHC main = defaultErrorHandler defaultDynFlags $ do session <- newSession (Just "d:/app/ghc-6.8.2") flags <- getSessionDynFlags session (flags, _) <- parseDynamicFlags flags [] GHC.defaultCleanupHandler flags $ do setSessionDynFlags session flags{ hscTarget=HscInterpreted } prelude <- findModule session (mkModuleName "Prelude") Nothing setContext session [] [prelude] runStmt session "let n = 2 + 2" RunToCompletion -- n is bound runStmt session "n" RunToCompletion -- 4 is printed (note "it" is bound) gives the following error when run from GHCi *Main> :load "l:/test.hs" [1 of 1] Compiling Main ( l:/test.hs, interpreted ) Ok, modules loaded: Main. *Main> main GHCi runtime linker: fatal error: I found a duplicate definition for symbol _forkOS_entry whilst processing object file d:/app/ghc-6.8.2/lib\base-3.0.1.0/HSbase-3.0.1.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Process haskell finished Is my code incorrect, or is this a (known?) bug in GHC 6.8.2 on Windows? I haven't tried the Linux version yet. NOTE: The program *does* run fine when compiling via GHC --make. Thanks, Peter
On 2008.01.09 17:07:46 +0100, Peter Verswyvelen
I while I ago I sent an email regarding hs-plugins not working on windows.
I now tried to directly use GHC API, but I also failed.
The following program (which might be buggy, I copy/pasted from various sources)
import DynFlags import GHC
main = defaultErrorHandler defaultDynFlags $ do session <- newSession (Just "d:/app/ghc-6.8.2") flags <- getSessionDynFlags session (flags, _) <- parseDynamicFlags flags [] GHC.defaultCleanupHandler flags $ do setSessionDynFlags session flags{ hscTarget=HscInterpreted } prelude <- findModule session (mkModuleName "Prelude") Nothing setContext session [] [prelude] runStmt session "let n = 2 + 2" RunToCompletion -- n is bound runStmt session "n" RunToCompletion -- 4 is printed (note "it" is bound)
gives the following error when run from GHCi *Main> :load "l:/test.hs" [1 of 1] Compiling Main ( l:/test.hs, interpreted ) Ok, modules loaded: Main. *Main> main
GHCi runtime linker: fatal error: I found a duplicate definition for symbol _forkOS_entry whilst processing object file d:/app/ghc-6.8.2/lib\base-3.0.1.0/HSbase-3.0.1.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry.
Process haskell finished
Is my code incorrect, or is this a (known?) bug in GHC 6.8.2 on Windows? I haven't tried the Linux version yet.
NOTE: The program *does* run fine when compiling via GHC --make.
Thanks, Peter
I think your installation is just buggy. I ran it here, and it compiles fine (although it doesn't run, as Linux obviously has "d:/app/ghc-6.8.2") and runs, printing "4" if I replace the string with "/usr/lib/ghc-6.8.2". Could it be that your GHCi is not the 6.8.2 one, or your path incorrect? -- gwern & b AHPCRC Playboy Dolch += SG530 Karimov CNCIS beef
gwern0@gmail.com wrote:
I think your installation is just buggy. I ran it here, and it compiles fine (although it doesn't run, as Linux obviously has "d:/app/ghc-6.8.2") and runs, printing "4" if I replace the string with "/usr/lib/ghc-6.8.2". Could it be that your GHCi is not the 6.8.2 one, or your path incorrect?
Interesting... But I don't see what could be wrong with my installation. I just downloaded and installed the binary installer from the Internet. I did have to expose the package ghc before GHCi could compile my code. I also just tried a clean install of GHC-6.8.2 on a brand new Windows XP SP2 system (that never had any GHC nor GCC nor MINGW installed before), but that also gives the same error. So I guess it runs fine on Linux (as you tested), but not on Windows? Thanks, Peter
Using ghci your code is fine under Linux, but fails on Windows, even with a daily snapshot from today. It's OK when compiling with ghc on both platforms.
"Attila Babo"
Using ghci your code is fine under Linux, but fails on Windows, even with a daily snapshot from today. It's OK when compiling with ghc on both platforms.
I think it is time for peter to become acquainted with the readline package and write a custom repl. Or just copy half of ghci into a module and call it. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.
I think it is time for peter to become acquainted with the readline package and write a custom repl.
No no, I already did that, a long time ago, in 68000 assembly :)
Or just copy half of ghci into a module and call it.
I'm just interested in seeing if the interpreter/compiler/linker infrastructure can be used as a library on both Linux/Windows/OSX, and for creating plugins at runtime. When using Microsoft's C#/.NET I used that a lot. On that platform it is very easy to generate code on the fly, call the C# compiler, emit code, load code, creating "plugins". But Microsoft.NET does not support Haskell :( F# is a good step forward, but it's not lazy, and I am.
Excerpts from Peter Verswyvelen's message of Wed Jan 09 10:07:46 -0600 2008:
Is my code incorrect, or is this a (known?) bug in GHC 6.8.2 on Windows? I haven't tried the Linux version yet.
The same thing happens on my Windows XP box as it does with yours. On both windows and my linux box, ghc --make works fine, and on linux with ghci, it works fine but not on windows (and fails with the exact same error.) Just from a general idea I would say that the reason would be related to the linker loading base twice: once when ghci itself is started, and the second time when you actually call into the ghc api; setSessionDynFlags will give your session knowledge of all installed packages, so when you're actually executing code using runStmt it may reload the object file into an address space where it already resides. GHCi only has one symbol table in its address space, so loading twice will naturally cause clashes. This seems slightly related to the fact that, you can't do similar with hs-plugins as it directly interfaces with the runtime linker and therefore you must always compile your apps that use hs-plugins rather than loading them into ghci. Why this would only occur on Windows and not linux though, I have no idea. It seems a bug report is well in order. I'm probably just talking nonsense though; I guess you'll just have to make due with ghc --make! Sorry I couldn't further help, you may get more info by asking a ghc guru. - Austin -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny
participants (5)
-
Achim Schneider -
Attila Babo -
Austin Seipp -
gwern0＠gmail.com -
Peter Verswyvelen