I found that if I compile it with GHC and _then_ launch GHCI it works, though using GHCI directly will not work if something is changed in the file and GHCI decides it must be recompiled.
$ ghc -c test.hs $ ghci test.hs
Weird. I hope someone with my same problem finds this solution and is saved some stress.
Federico Zenith <non.mi...@mma.re> wrote: > Federico Zenith wrote: >> I have this problem with the following snippet:
>> --------------------------------- >> {-# LANGUAGE ForeignFunctionInterface #-}
> module Test where
>> import Foreign.Ptr
>> foreign import ccall "stdlib.h &free" >> p_free :: FunPtr (Ptr a -> IO ()) >> --------------------------------- > I found that if I compile it with GHC and _then_ launch GHCI it > works, though using GHCI directly will not work if something is > changed in the file and GHCI decides it must be recompiled. > Weird.
Ok, exercise for the reader: Have you figured out *why* it behaves this way? (Hint: GHCI *interprets*, GHC *compiles*. Now combine this information with "via-C".)
Dirk Thierbach wrote: > Ok, exercise for the reader: Have you figured out *why* it behaves this > way? (Hint: GHCI *interprets*, GHC *compiles*. Now combine this > information with "via-C".)
Well it stays weird since GHCI makes use of the compiled code it finds (if it finds it) instead of interpreting the file. The error message could have been a bit more helpful, anyway. Also, the "via-C" part was not required when compiling with GHC.
Federico Zenith <non.mi...@mma.re> wrote: > Dirk Thierbach wrote: >> Ok, exercise for the reader: Have you figured out *why* it behaves this >> way? (Hint: GHCI *interprets*, GHC *compiles*. Now combine this >> information with "via-C".) > Well it stays weird since GHCI makes use of the compiled code it finds (if > it finds it) instead of interpreting the file.
Correct. But that's not weird, that's the intended behaviour: If a current object file is around, why not use it instead of doing the compilation all over?
> The error message could have been a bit more helpful, anyway. > Also, the "via-C" part was not required when compiling with GHC.
Yes. If you look up -fvia-C in the GHC manual, section flag reference, you're redirected to section 4.10.6 (Options affecting code generation). There you'll find, near -fvia-C:
: -fobject-code : : Generate object code. This is the default outside of GHCi, and can : be used with GHCi to cause object code to be generated in preference : to bytecode. : : -fbyte-code : : Generate byte-code instead of object-code. This is the default in : GHCi. Byte-code can currently only be used in the interactive : interpreter, not saved to disk. This option is only useful for : reversing the effect of -fobject-code.
That explains why it works with GHC, but not with GHCI. And:
Prelude> :l yyy.hs [1 of 1] Compiling Test ( yyy.hs, interpreted )
yyy.hs:7:0: Illegal foreign declaration: requires via-C or native code generation (-fvia-C) When checking declaration: foreign import ccall safe "static stdlib.h &free" p_free :: FunPtr (Ptr a -> IO ()) Prelude> :set -fobject-code Prelude> :l yyy.hs [1 of 1] Compiling Test ( yyy.hs, yyy.o ) Ok, modules loaded: Test.
It works even in GHCI :-)
(Yes, you have to know what "native code generation" means, and -fvia-C is a bit misleading, because it is a second requirement, which is probably automatically set by the FFI option (I didn't check). But at least it points you in the right direction. RTFM helps, of course. And it's not really surprising that FFI code does need C code instead of bytecode).
|
