[ocaml-ctypes] libffi compatibility

[Anil Madhavapeddy]

On 3 Oct 2013, at 18:22, Phil Hagelberg <phil at hagelb.org> wrote:

> 
> I'm preparing to distribute my ctypes-using project to folks who don't
> have OCaml installed, so I'm compiling a .native executable.
> 
> Most of what I read about distributing OCaml is that for native binaries
> you can compile it on any 64-bit Linux system, and it should work on any
> other 64-bit Linux. But I get the feeling libffi complicates things a
> bit; my Debian-compiled binary refuses to run on newer Ubuntus ("error
> while loading shared libraries: libffi.so.5: cannot open shared object
> file") and straight up segfaults on Fedora 19.

Right; while static linking is (reasonably) doable on Linux, libffi
introduce a dynamic loading component.  You may want to try to link to
libffi statically from ctypes, which would link in libffi.a instead of
libffi.so.<major>.

In the longer term though, I'm finding it's easier to distribute a
source version. If your users don't have OCaml installed, would they
be satisfied with a script that outputs a native executable? For instance,
I added a 'make cold' target to OPAM 1.1 that bootstraps it without OCaml
installed, and then that's sufficient to build any OPAM library without
a compiler.  It does take a little longer though...

> So I'm guessing I'll need to compile separately for each
> distribution/version I want to support? Are there any tools to make this
> process more streamlined? I briefly looked at the OpenSuSE Build
> Service[1], but it looks pretty complicated. What about different
> versions of Mac OS X?

I've slowly been working through this for OPAM itself, and I'm afraid
there aren't really any clear services on this front that don't involve
a lot of manual gruntwork.

> Also on a somewhat-related note, I have this to find the readline library:
> 
>  let libreadline = Dl.(dlopen ~filename:"libreadline.so" ~flags:[RTLD_NOW])
> 
> However, the ".so" needs to be replaced with ".dylib" for Mac OS X
> compatibility. Is there a recommended way to specify dlopen filenames
> portably, or should I just catch the exception and try to fall back to
> .dylib if it can't find the .so?

It's probably best to embed a -cclib -lreadline that will cause the
system linker to do the right thing, rather than dlopen it manually.
Do you specifically need to do this at runtime via Dl.dlopen, or would
some build assistance help out here?

-anil