`-fprefer-bytecode` broken in presence of CApiFFI
CApiFfi
imports are currently implemented via the production of a stub object during desugaring. This is problematic in the case of modules loaded from serialised bytecode with -fprefer-bytecode
since desugaring is not run.
For instance, imagine a simple C function:
int say_hello() { return 42; }
and a module with capi
import (e.g. used in a TemplateHaskell splice):
{-# LANGUAGE CApiFFI #-}
{-# LANGUAGE ForeignFunctionInterface #-}
module Hello where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
foreign import capi "hello.h say_hello" say_hello :: IO Int
mkHello :: DecsQ
mkHello = do
n <- runIO say_hello
[d| hello :: IO Int
hello = return $(lift n) |]
if one compiles Hello
with -fbytecode-and-object-code
and then attempt to splice mkHello
in a module compiled with -fprefer-byte-code
compilation will fail with a linker error:
/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -c hello.c
/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -c -fbyte-code-and-object-code Hello.hs
compilation IS NOT required
/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -fprefer-byte-code hello.o Main.hs
[2 of 3] Compiling Main ( Main.hs, Main.o )
ghc: ^^ Could not load 'ghczuwrapperZC0ZCmainZCHelloZCsayzuhello', dependency unresolved. See top entry above.
<no location info>: error:
GHC.ByteCode.Linker: can't find label
During interactive linking, GHCi couldn't find the following symbol:
ghczuwrapperZC0ZCmainZCHelloZCsayzuhello
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
This was astutely noticed by @phadej .