[ocaml-ctypes] libffi compatibility

[Phil Hagelberg]

Anil Madhavapeddy writes:

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

That sounds promising; can you explain how it would work? I don't see it
mentioned in the ctypes documentation.

My suspicion is that readline is much more stable than libffi, so while
technically there could still be incompatibility dynamically loading
readline, in practice it would be much less common than incompatibility
arising from dynamically loading libffi. But that's just a wildly
unqualified guess.

> 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?

It's tempting, but I think most of my users wouldn't be interested in
trying this program if the installation took half an hour. Of course
it's always an option for users on systems where I can't provide a
precompiled binary, but those people typically have more patience to
begin with. =)

>> 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?

I've never worked with C libraries before; I was just following the
advice I found on the issue tracker regarding a similar problem:

  https://github.com/ocamllabs/ocaml-ctypes/issues/70

Is changing my `ocamlbuild` invocation the best way to do that?

  $ ocamlbuild -use-ocamlfind -lflags -cclib,-lreadline grench.native

For context, the project in question is here:

  https://github.com/technomancy/grenchman

thanks,
Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.ocaml.org/pipermail/ctypes/attachments/20131004/b4678eef/attachment.sig>