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 num
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).