[opam-devel] conf- libraries and stub cmas: time for ocaml-discover?

Anil Madhavapeddy anil at recoil.org
Mon Aug 26 11:57:40 BST 2013


I wanted to follow up on this ticket in OPAM-repository with a slightly wider audience, as it affects a lot of the libraries in the tree.
https://github.com/OCamlPro/opam-repository/pull/1008#issuecomment-23250671

Christophe makes the suggestion of having the stub packages for conf-* libraries expose their cflags/lflags in a standard-ish way that can be used by the OCaml package.

We have a similar problem with an upcoming version of the ctypes library that supports linking to C libraries in several ways:

- Dynamically opening the symbols via dlopen(3) and using libffi to call functions.  No C stubs needed.

- C stub generation that outputs C code that is then compiled and linked in as usual.

- Struct "offset probing" that determines precisely which offset a field name maps to by generating enough C code to compile a test. [1]

Ideally, we would be able to query three types of information from a conf package installation:

- an ML file that has values exposing cflags/lflags as OCaml values.  This can be used by discover.ml scripts (as used in Core or Lwt)

- a CMA file that embeds the dynamic linking flags via cclib, including adding -Wl,--no-as-needed on newer systems like Ubuntu.  This lets a Ctypes using dynamic linking (Ctypes.Foreign) just add a CMA to the link line and have the correct gcc/clang libraries work.

- The final thing is some way to pass the right CFLAGS/LDFLAGS to compile up generated C stubs with the right include/library paths to gcc (either from Ctypes, or via the traditional camlidl/swig outputs).  Presumably this would be a raw shell fragment in a file, as usually output by autoconf.

Overall though, it does seem time to come up with a concrete proposal for how to handle system-specific C library configuration.  If we get this right, it should significantly simplify win32 and cross-compilation too.

I'm thinking of an ocaml-discover package that can encapsulate all this stuff and provide a single place for all this stub logic.  Anyone else have any thoughts that I've missed out above?

[1] https://github.com/ocamllabs/ocaml-ctypes/issues/55


More information about the opam-devel mailing list