Two Library of Different Versions in an Application

Application linking 2 versions of same library due to dependencies

The right solution was to make the library, which is linking libpng3, link it in private mode:

target_link_libraries(${TARGET} PUBLIC 
    VigFramework
    PedestriansBDI_Base
    DIGUY::GraphicsApi
    DIGUY::Main
    DIGUYDevil::Main
    TBB::Main2
    Qt4::QtCore
    Qt4::QtSql
    Qt4::QtGui
    Qt4::QtXml
    Qt4::QtNetwork
    Tiff::Main
)

target_link_libraries(${TARGET} PRIVATE 
    PNG3::Shared #required for DIGUY
)

This will guarantee that the main application links with libpng15 and does not get polluted by libpng3 from the other libraries.

How to include different versions of same static library in an application?

How to make sure that function calls from AA.so go to CC.a version 1 and calls from BB.so go to CC.a version 2?

You can't: making sure involves building AA.so and BB.so in a self-contained manner, and you can't rebuild them.

What you can do is try to make this work by loading the libraries at runtime using dlopen("AA.so", RTLD_LAZY|RTLD_LOCAL) and same for BB.so, and hope that the libraries don't step on each other.

In theory that (RTLD_LOCAL is the important bit) should work. In practice, there are many ways this could still break; you are venturing into very dangerous ground.

It could also work today, but break when either shared library is updated. You really should work with your library suppliers to get out of this multiple incompatible version mess.

Update:

I believe shared objects do not depend on anything else and in that sense they are self-contained.

The "not depend on anything else" part is necessary, but not sufficient.

Normally, a shared library exports all global functions and data linked into it. Suppose CC.a contains a global function foo; suppose that versions 1 and 2 of this function are not compatible, and that foo is exported from both AA.so and BB.so. In that case, whichever library is loaded first will win. If AA.so is loaded first, then a call from BB.so to foo will get resolved to the definition inside AA.so, and your program will either corrupt its state, or crash.

To verify that this is not the case, you should run nm -D on AA.so and BB.so, and confirm that the intersection of symbols exported from these libraries is empty. If it is not empty, you have to verify that the two definitions are compatible.

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 can I install two different versions of the same dependency on the same project?

You can use aliases if you really need to do this. Look up npm aliasing.

@angular/common: '13.0.0',
@myangular-custom: '4.0.0

Please don't take this example literally but this is the gist of it.?
This should better answer your question...

How to install NPM package under alias or different name

---

Related Topics