LLVM: symbol not found for bytecode compilation

One practical consideration about how to implement bindings for llvm is that the upstream build bots, and llvm developers generally, do not have many ocaml-specific tools. I’m not sure, but it might be difficult to use an approach that needs additional tools or libraries to be installed. Another thing to consider is @kit-ty-kate’s llvm-dune project.

I have also been thinking about the question of where one language binding of a library should reside.

My observation on z3 and llvm is

  1. the source code of binding is in their source truck.
  2. META is in their source truck.
  3. OCaml binding is built with specific commands.
  4. The binding building requires OCAMLFIND to be installed.
  5. opam files are in OCaml’s opam-repository. So, it’s out of their business to publish them.

It seems to build the binding, ocamlfind is the minimal tool to have (of course with ocaml itself).

This is for the case when the binding is in-the-tree. There is also the case when it’s totally out-of-tree, e.g. clangml.

After all, who is concerning more whether OCaml users can use the library fluently? Is it the seller’s market or buyer’s market?

Personally, I think llvm-dune is definitely a better solution to distributed llvm in the OCaml world.

I agree that there are advantages to having the bindings out of tree. There are also advantages to having them in the tree though. I have seen more cases of a test failing when something is changed in the LLVM C API, leading the patch author to fix the ocaml bindings. I don’t know the optimal way, just noting that there are advantages both ways.

Currently, the blocker to having the opam file in the upstream trunk is the patches in the opam package that are applied to adjust the build system. If the differences between the upstream build scripts and the opam package could be eliminated, and if the opam file could be placed in the ocaml bindings directory (not at the root of the repo), then I do not think that there would be problems adding the opam file upstream.

Please feel free to add me as a reviewer to any changes sent upstream.