Calling dynamically linked Haskell code from Rust

Question

I'm trying to compile some Rust code with some Haskell code. I have a test system set up with a file, Fibonacci.hs with a function which computes fibonacci numbers in Haskell and exports the function as fibonacci_hs via Haskell's FFI (as here: https://github.com/nh2/haskell-from-python, though I'll copy and paste at the bottom), and in wrapper.c have defined the functions to export to be called for initializing and exiting Haskell's RTS.

The code looks like this:

{- Fibonacci.hs -}
{-# LANGUAGE ForeignFunctionInterface #-}

module Fibonacci where

import Foreign.C.Types

fibonacci :: Int -> Int
fibonacci n = fibs !! n
    where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

fibonacci_hs :: CInt -> CInt
fibonacci_hs = fromIntegral . fibonacci . fromIntegral

foreign export ccall fibonacci_hs :: CInt -> CInt

---

// wrapper.c

#include <stdlib.h>
#include "HsFFI.h"

void
example_init (void)
{
  hs_init (NULL, NULL);
}

void
example_exit (void)
{
  hs_exit ();
}

I compile these via:

ghc -c -dynamic -fPIC Fibonacci.hs

ghc -c -dynamic -fPIC wrapper.c

and I link the objects into a shared/dynamic library (more on this in a second) via:

ghc -o libfibonacci.so -shared -dynamic -fPIC Fibonacci.o wrapper.o -lHSrts

On running the Python example code from the linked repository, it runs just fine on my mac, but I can't get it to link with Rust.

In Rust my code looks something like this:

//main.rs
#[link(name = "fibonacci")]
extern {
    fn fibonacci_hs (n : i32); // c_int = i32
    fn fib_init (); // start hs rts
    fn fib_exit (); // kill hs rts
}

fn main () {
    unsafe {
        fib_init();
        for i in 0..100 {
            println!("{:?}th fibonacci : {:?}", i, fibonacci_hs(i));
        }
        fib_exit();
    }
}

And I compile with rustc main.rs -L . (since shared library file is local).

The error I generate on Mac, when compiled with a dynamic library (ghc -o libfibonacci.so -shared -static haskell/Fibonacci.o haskell/wrapper.o -lHSrts then 'rustc main.rs -L . ) is at runtime:

dyld: Symbol not found: _ffi_call
  Referenced from: ./libfibonacci.so
  Expected in: flat namespace
 in ./libfibonacci.so
Trace/BPT trap: 5

Thanks for any help in advance.

Answer 1

When you compile your shared library, it looks like you need to link against libffi as well:

ghc -o libfibonacci.dylib -shared -dynamic -fPIC \
  Fibonacci.hs wrapper.c -lHSrts -lffi

I deduced this by going into my GHC library directory (/usr/local/lib/ghc-7.10.1/rts) and then grepping for the symbol ffi_call:

$ grep -lRa ffi_call .
./include/ffi.h
./rts/libHSrts-ghc7.10.1.dylib
...

I then used nm to find which exact library had it:

for i in *dylib; do
   if nm $i | grep -q 'T.*ffi_call'; then
       echo "== $i";
   fi;
done

I was then able to run with:

DYLD_LIBRARY_PATH='.' ./main

Unfortunately, it appears your code isn't quite right, as I just get a bunch of empty tuples. You forgot to have a return type on the function, and then you run into a problem that the 46th or so Fibbonacci is too big for a u32.

Additionally, you should be using the types from the libc package, and it may be safest to use a u64 here.

I have installed GHC 7.10.1 using Homebrew, but hopefully the same pattern would work elsewhere.

Answer 2

You mention two different final link commands,

ghc -o libfibonacci.so -shared -dynamic -fPIC Fibonacci.o wrapper.o -lHSrts

and

ghc -o libfibonacci.so -shared -static haskell/Fibonacci.o haskell/wrapper.o -lHSrts

It might be worth explicitly describing what some of these flags mean.

• -shared tells ghc to produce a shared object (rather than an executable).

• -dynamic tells ghc to link the output against the dynamic library versions of its Haskell dependencies (base, ghc-prim, etc.)

• -static is the opposite of -dynamic, it tells ghc to link against the static library versions of Haskell dependencies.

• -lHSrts means to link against the (static or shared) library libHSrts. But in GHC, only the static library actually has the basename libHSrts (so that the library file name is libHSrts.a). The shared library version has file name libHSrts-ghc7.8.4.so (adjust for your GHC version). So, -lHSrts really means to link against the static library version of the RTS.

So the second command is linking against the static versions of all Haskell dependencies, including the RTS. This may work on OS X where all code must be generated as PIC, but it won't work on a normal Linux binary distribution of GHC because a shared library must be PIC code, but the static Haskell libraries shipped with GHC are built as non-PIC (they are intended to be linked into non-relocatable executables). I don't totally understand why GHC is not smart enough to add -lffi itself here, possibly it doesn't really expect this combination of options since it won't work on a normal Linux setup.

The first command is odd, because you are linking statically against the RTS, but dynamically against all other Haskell dependencies. If you change the library name in the -l option to -lHSrts-ghc7.8.4, then things will Just Work on Linux, and probably everywhere else (other than Windows).