How to handle common c++ libs in C++/Rust projects

So for example, I have a slightly complicated case of library dependency in one of my projects:

              /--------------------------------\
              |                                |
      /----> GRPC <------------------\         |
      |                              |         |
      |        (c++)                 |         |        
      \-------   A  -------------->  B         |
                 |                 (rust)      |
                 |                             |
                 \------------------> c++  <---/ 

(A is a binary, B is a lib)

Possible solutions:

  1. Set B as a shared library: it works. But B itself contains a complete definition of GRPC, there are potential violation of ODR.
  2. Set B as a static library: Again B itself contains a complete definition of GRPC, so there will be multiple definitions.
  3. Use B as GRPC provider: So I need to maintain GRPC together with B. It is not practical.

(Actually,my current solution is 1, but A even depends on a static libc++ [maybe I should change that], so I think there is a serious ODR violation)

I wonder if anyone is also facing this situation. And any better idea?

I'm not quite sure how A and B are interacting so this might be a naive answer, but what about compiling B to a shared library and making sure the only thing passed across the FFI boundary is serialized protobuf messages?

My understanding is that the Rust compiler will bundle everything it needs inside a shared library, so even if B and A use functions and types with the same names, you won't have any ODR violations because B never tries to use GRPC stuff from A, and vice versa.

Protobuf messages are designed for forwards/backwards compatibility out of the box, so that should help deal with any slight versioning differences between A and B.

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.