Re: [Haskell-cafe] FFI question - FunPtrs to top-level functions
On 8/18/2011 6:49 AM, Antoine Latter wrote: Hi Haskell, I have a question about the Haskell FFI and creating FunPtrs to Haskell functions. Does anyone have any recommendations for when I have a top-level function that I would like to pass to a C function as a function pointer (that is called via a foreign import)? I know that the FFI provides the wrapper foreign import I can use to wrap Haskell functions, but then I would need to jump through hoops to manage the liefetime of of the FunPtr wrapper. If I were closing over interesting state I would want this - but the function (side-effectfully) operates only on its arguments (and the Haskell RTS, of course). Is it okay to place an unsafePerformIO $ mkWrapper myFunc as a top-level declaration, or am I journeying into uncharted lands? Is there something clever I can do with foreign exports and foreign imports, or is this just making things too complex? Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe You can export and reimport the same function with no wrapper needed. For example: foreign export ccall foo :: ... foreign import ccall foo fooptr :: FunPtr (...) Cheers, Kyra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On 2/9/06, Frederico Franzosi [EMAIL PROTECTED] wrote: Hi, I don't really know how this stuff exactly works, but here's few things I have found useful when I ran into this sort of problems. I'm developping a package wich imports C functions. For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) I don't have exact answer, but ghc uses ld under the hood and sometimes the order of libraries on ld command line matters. Here's few things that might be useful if that's the case. Use ghc -v and find final link ld/gcc (I don't recall which one ghc invokes for linking) and try that line yourself, you can also move libraries up on list etc to find what order you actually need. Add -llib to the options in package.conf as a library- try adding as first and try adding as last. Try both ;-) Try adding as object file, ie /path/to/lib.a Order of arguments on ghc command line doesn't matter so much, because ghc will put (if I recall correctly) package libraries first and then add -llib and such options to the end on the ld command line- so it's pretty hard to work around the problem just by invoking ghc different way. $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. and also when I do: $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a If I were to guess these work because /path/to/lib.a is handled as an object file, which is somehow different from being library. I have no knowledge what and why there is this sort of magic restrictions. HTH, -Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On Thu, 9 Feb 2006, Christopher Brown wrote: Frederico, Have you tried using Green Card? http://haskell.org/greencard/ It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way. I tried it, and managed to get it working to some extent. Then I found out about hsc2hs and the current FFI support in ghc, and I noticed that according to http://www.haskell.org/greencard/ , the current version of Green Card is an alpha release from 2003. From comparison of the two, my impression is that this parrot is dead, and everyone is just too polite to say so. Unfortunately, this inability to pull the shades on Green Card, Haskell Direct, etc., takes away a little from ghc's outstanding FFI. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
