Re: [Haskell-cafe] Creating DLLs with GHC

Jason Dagit wrote:

On 9/27/06, SevenThunders wrote:

...

Does cabal really work on windows?

I've never had a problem with cabal on windows. I use it instead of makefiles and I'm reasonably happy with it.

...

Although it's installed I notice that when I try to build my library using it, it dies on the first foreign import statement in the first .hs source it tries to compile. It is reminiscent of trying to import a foreign C module directly ghci. ghc.exe, on the other hand has no problem with it.

Perhaps your .cabal file is not correct or your cabal version is too old? It's very hard to say without detailed error messages and a clear description of what you're doing (with sample code).

...

Does this scheme address the problem of being unable to link external C libraries (a DLL) into the Haskell DLL? Are there any other workarounds here?

I only create a DLL from haskell and link that in a C++ application. I haven't tried the other way. Probably over the next month or so the DLL I'm creating in Haskell will need to access an existing DLL. Hopefully this will work fine.

...

Is it possible to create static link libraries compatible with MS VC++? Ultimately I'm trying to link my C code with Matlab. The C code stub will then call a bunch of Haskell routines.

I have no idea. I'm fairly new to using Haskell in windows.

Jason _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Actually I've had no problems linking external C DLLs into Haskell. I suspect that I can even create Haskell DLLs provided I'm not also externally linking a C library. The problem appears to be doing both at the same time. That is creating a DLL from Haskell source that also links to an external DLL. Right now it seems that something strange is happening with the linker. I have this statement approximately ghc --mk-dll -fglasgow-exts -fffi -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -package parsec -optl-lmatrixstack -optl-L"." matrixstack.lib was created with dlltool.exe on windows so it should be gcc compliant. Now I've tried the following variations with the -optl-l argument. -optl-lcheese compiler doesn't complain about the cheese library not existing (matrixlib links still unresolved of course). This is a bad sign. -lmatrixstack compiler complains that matrixstack doesn't exist. This is true even if I create libmatrixstack.a matrixstack.a libmatrixstack.lib matrixstack.lib If I add a -L"." argument (instead of optl-L) I get the same behavior as the original case. No complaints about not finding matrixstack.lib, but a bunch of unresolved references from this library. In the latter case, however a -lcheese argument does result in an error saying it can't find cheese. Keep in mind that compiling the standalone executable (without the --mk-dll flag) works just fine with the original -optl options linking to the matrixstack.lib library. Could this be a bug with my version of ghc 6.5, or perhaps a known issue? There is some statement about not being able to create multiple DLLs for a single project. Am I running up against such an issue? This would be surprising since presumably the compiled C code in the static library matrixstack.lib performs the external DLL access independent from what Haskell is doing. -- View this message in context: http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6536057 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.