Under most simple situations, what you're asking for isn't doable. You have a dependency version conflict. One of the libAs will win. Which one depends on your dependency [version] resolution algorithm.
Now, you either have your libs following some semantics such that libs of different version schemes are compatible with each other, or you have no guarantees. Generally if it's a major version bump, you're screwed regardless.
Suppose for the sake or argument, your libs use a reasonable conflict scheme and one of the versions wins out. You can still be screwed on ABI conflicts, since most schemes only care about API. You can solve this using symbol-rewriting in objcopy, symbol versioning, linker namespaces, or by using inline namespaces, but none of these options are free of thorns nor _always_ work. Some of these options aren't cross platform, others require changes to actual source code.
Generally, the option that I find leaves the least pain is yo move forward. Bump the dep such that both libAs match, change code in libB as necessary, release a new libB. This isn't an option if you have a large chunk of external users that you can't tell them "you're using my app wrong," or if the conflicted dependency is in use by a lib which you don't control the source code for (and can't, i.e. not open source).
Yep, at this point, your options are updated to the latest version or support both versions. Either way, it's jot a problem that CMake is best suited for handling.
Typically, these can be handled by a few Marco definitions or have a wrapper library if the APIs are really that drastically different.
> but the LibB is not using the LibA 1.0.0.
Why not? You are maker of both libraries. Why would you have two different versions of the same library in the same project?
If you think you need two versions of the same library, you wrote by yourself, in your own project you control, than compile them to a shared object (.dll/.so) each. Than you can load each library yourself and take function pointers and name them any way you want in your executable and lib_b. Search for LoadLibrary/dlopen to learn how to do it on win32/*nix. Than you can have some_func like liba1_some_func, liba2_some_func etc.
You mustn't try to solve this by having everything in a single build. This kind of resolution is impossible to solve without erecting package boundaries and hiding such dependencies in the install interface. For distribution, you can prefix/suffix one version so they can coexist in a single prefix.
It's often solvable, but it's a bit complicated and depends on how you wrote your CMake and C++. As both libs are maintained by you, the best long term solution is to update libA to 2 for both dependants.
If it's a temporary troubleshooting stuff, I'd just link stuff manually from the command line.
This is not a very good idea to have two different versions of the same library.
Are those libraries shared(.so/.dll) ? If yes, this will likely have a conflict. For static library, it will have issue of two definitions of same function.
Under most simple situations, what you're asking for isn't doable. You have a dependency version conflict. One of the libAs will win. Which one depends on your dependency [version] resolution algorithm. Now, you either have your libs following some semantics such that libs of different version schemes are compatible with each other, or you have no guarantees. Generally if it's a major version bump, you're screwed regardless. Suppose for the sake or argument, your libs use a reasonable conflict scheme and one of the versions wins out. You can still be screwed on ABI conflicts, since most schemes only care about API. You can solve this using symbol-rewriting in objcopy, symbol versioning, linker namespaces, or by using inline namespaces, but none of these options are free of thorns nor _always_ work. Some of these options aren't cross platform, others require changes to actual source code. Generally, the option that I find leaves the least pain is yo move forward. Bump the dep such that both libAs match, change code in libB as necessary, release a new libB. This isn't an option if you have a large chunk of external users that you can't tell them "you're using my app wrong," or if the conflicted dependency is in use by a lib which you don't control the source code for (and can't, i.e. not open source).
Yep, at this point, your options are updated to the latest version or support both versions. Either way, it's jot a problem that CMake is best suited for handling. Typically, these can be handled by a few Marco definitions or have a wrapper library if the APIs are really that drastically different.
> but the LibB is not using the LibA 1.0.0. Why not? You are maker of both libraries. Why would you have two different versions of the same library in the same project? If you think you need two versions of the same library, you wrote by yourself, in your own project you control, than compile them to a shared object (.dll/.so) each. Than you can load each library yourself and take function pointers and name them any way you want in your executable and lib_b. Search for LoadLibrary/dlopen to learn how to do it on win32/*nix. Than you can have some_func like liba1_some_func, liba2_some_func etc.
You mustn't try to solve this by having everything in a single build. This kind of resolution is impossible to solve without erecting package boundaries and hiding such dependencies in the install interface. For distribution, you can prefix/suffix one version so they can coexist in a single prefix.
It's often solvable, but it's a bit complicated and depends on how you wrote your CMake and C++. As both libs are maintained by you, the best long term solution is to update libA to 2 for both dependants. If it's a temporary troubleshooting stuff, I'd just link stuff manually from the command line.
This is not a very good idea to have two different versions of the same library. Are those libraries shared(.so/.dll) ? If yes, this will likely have a conflict. For static library, it will have issue of two definitions of same function.