Cargo/dune integration

Has anyone had some success integrating cargo with dune on something beyond one library + one executable scenario?

I’ve tried the approach of building Rust static C lib per foreign archive, it looks quite promising and I explained it in details in this issue of ocaml-rs project. But I got stuck at “diamond dependency problem”, when two foreign archives depend on some common Rust dependencies (and they always do, because of stdlib dependency in each of foreign archive) - linking fails due to duplicate symbols when I try to use two Dune libraries, binding Rust, in one executable.

Rust can produce an “rlib” type of artifact, which happens to be an ar archive containing only artifacts from the current crate, without any dependencies. Folks integrating Rust to Bazel are using this type of output from Rust, and manage dependencies on their own to pass all the archives at the final link stage to avoid the diamind dependency problem.

I tried to apply this approach to Dune, but it failed straight away - linking of my Dune library failed when I tried to use “rlib” as static library for C stubs, linker complained about all the missing symbols.

Is it possible to delay the linking of Dune library until it’s linked to final executable?

Another option that Rust offers is building a dynamic library, and in this case Rust is able to hide all non extern "C" symbols, and probably using multiple such shared libraries within one executable should be working just fine (aside of code bloat, but oh well). Can Dune link to C stubs which are contained in dynamic libraries?

3 Likes

I am also working on Rust/OCaml integration. I am curious what is a concrete example of needing this. Thanks!

I’m not sure I fully understand the question. It’s practical to split your codebase into multiple libraries, some of which you might want to distribute either internally within your company, or externally via opam-repository/crates.io. Currently doing this is quite challenging. There is blake3 opam package, that is actually a Rust bindings library, and you will run into linking issues if another such package emerges on opam and you happen to need both in the same executable.