C++ Two Libraries Depend on Same Lib But Different Versions

C++ two libraries depend on same lib but different versions?

I'm assuming that you're linking dynamically. If both A and B completely encapsulate their respective versions of C then it might be possible to do this. You might have to make sure that the different versions of C are named differently (i.e. libMyC.1.so and libMyC.2.so) to avoid confusion when they are loaded at runtime.

You could also investigate statically building A and B to avoid the possiblility of runtime load confusion.

Simplest way to find out is simply to try it. It shouldn't take to long to determine if it'll work or not.

Lastly, of course, by far the easiest solution, and best from a maintenance perspective is to bring A, or B, up to the level of the other so that they both use the same version of C. This is better in so many ways and I strongly urge you to do that rather than to try working around a real problem.

How to load two versions of a library in the same process in Linux?

If you control the code which consumes this library, an easy course of action would be either upgrade/downgrade, so you don't rely on two distinct versions of the same library. If another part of your project also depends on that library or you have the same problem with another third-party library, you will have more work. This can slow down your upgrade path.

If this is a large project and the two endpoints are unrelated, you may want to split them up into separate services/process, with some interprocess communication (IPC) layer in-between. Examples being message-queues, pipes or sockets. This approach is known as the microservices architecture. In some ways, this solution scales better, you have the overhead introduced by the IPC layer, but the new structure may be easier to understand, debug and test.

Another approach is to implement the functionality of this third-party dependency yourself. You can satisfy the requirements for both versions. If the library is open-source, then half of the work is already there. This option provides great flexibility, as you can tailor it to your needs, at the expense of developer overhead.

Your solution of using export mapping is valid but may be difficult to maintain, so I would not recommend it. For large libraries, it may not even be feasible without scripting. What happens when you want to upgrade?

Related Topics