Search code examples
linuxdynamicsymbolsversioningloader

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

I am working on a project where I need to load two versions of the same library in the same application in Linux. What I found is that to be able to do this successfully without any library conflict issue, I have to symbol version both the versions of the library using its own export maps. It seems like if the running application has this sort of references, "name@@nodename", the dynamic loader in Linux will look for name only in nodename and not elsewhere. This is what I have concluded for the reason to symbol version both the libraries. Is this reasoning correct? Are there any other options to load two versions of the same library in the same application without library conflicts?

Solution

  • 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?