Diamond dependency with dylibs

Just want to make sure I'm heading in the correct direction. In the case where B, C, and D are my crates, nix is a common dependency of B and C.

      nix.rlib
       /    \
  libB.so  libC.so
       \    /
      libD.so

B, C, and D are needed to be dynamic libraries (for dlopen). Does it imply that the only chance for me to build D (and also to make sense of the entire procedure) is to make nix and all its transitive dependencies to produce dylibs for B and C to link with (perhaps by customizing cargo a little bit)? Assume ABI compatibility is achieved by forcing the use of the same compiler. @bjorn3

In my real case, I have more than 30 custom crates and the dependencies are much more complex than in the case described above.

You can make only nix a dylib, but keep the dependencies of nix rlibs. Then those rlibs will be linked into libnix.so automatically.

2 Likes

Thanks for the tip @bjorn3. I actually saw cargo-add-dynamic a few days ago, but it didn't solve my problem.

There is an important limitation in the approach of adding a dylib shim, which is described

In my setup, I have already written 40k LoC and dozens of crates. The diamond dependency issue appears when I am doing a large refactoring to the codebase. Adding a dylib shim, unfortunately, merely works in the toy case scenario. I guess this is why I'm thinking about whether transparently producing a dylib for each crate and linking them together would work.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.