Re: FFI, DLL Linking, Windows Haskell Platform 2010
Nabil Alsharif <[email protected]> Mon, 04 Apr 2011 08:55:34 -0500
| Newsgroups | gmane.comp.lang.haskell.ffi |
|---|---|
| Message-ID | <[email protected]> |
Thank you very Mr. Thielemann. I got everything working under linux, ghc links to distorm and the library compiles and works. After a little investigation I found out that, under windows, distorm is compiled using MSVC and I had used MSVC to compile the test C program I had written to make sure I could link to distorm before I started messing with ghc and FFI. The catch is that if I try to compile the test C program with gcc under windows it fails :-(. So I guess in the end this want really a ghc issue and it's more of a microsoft awesomeness issue, and made worse by distorm's support for mingw being broken. Thanks for the Cabal link, I'm gonna write a Cabal package for this sooner or later. The reason for using distorm is because we need to replace the disassembler pack with something more versatile. Nabil Alsharif. On 04/03/2011 02:57 PM, Henning Thielemann wrote: > Nabil Alsharif schrieb: > >> The issue is when I try to compile the library the linker goes haywire: >> C:\Users\tantalum\Documents\Research\distorm_test>ghc --make Main.hs >> [2 of 2] Compiling Main ( Main.hs, Main.o ) >> Linking Main.exe ... >> .\Distorm3.o:fake:(.text+0x11b): undefined reference to `distorm_version' >> collect2: ld returned 1 exit status > > You must link the distorm library into the executable. Say: > > $ ghc -ldistorm --make Main.hs > > It should work this way on Unix at least. > > >> C:\Users\tantalum\Documents\Research\distorm_test>ghc --make Main.hs -l distorm3 > I don't know whether the argument order matters. > >> Linking Main.exe ... >> C:\Program Files (x86)\Haskell Platform\2010.2.0.0\mingw\bin\ld.exe: cannot find >> -lC:\Users\tantalum\AppData\Local\Temp\ghc5976_0\ghc5976_0.o >> collect2: ld returned 1 exit status >> >> Any ideas or suggestions? What is that temporary object file for? > You may also try to let Cabal handle the calling of GHC. You may start > with an existing C library binding and adapt it to your needs. E.g. > http://code.haskell.org/jack/jack.cabal > > > You may also be interested in the disassembler package at Hackage: > http://hackage.haskell.org/package/disassembler-0.1.0.1