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