Two plugins linking to identically named DLLs or shared library object (so) with different implementation (code)

Question

I have two "plugins" (think of them just as two different applications in a software package for discussion sake) that dynamically link to two separately built versions of my library. My code is written in C++ and uses consistent namespaces throughout. Sometimes I have to build two different versions for each application. This appears to cause some problems when both applications (plugins) in the package are loaded simultaneously. First I need help understanding why this error occurs.

As an example, I have two separate but identically named libraries, say mylib.so (or DLL) and each application is linking to (unique) one of these. If the underlying code in mylib.so is the same (i.e., namespaces, names of functions, etc. with slightly different implementations of course) should this cause problems? Isn't the fact that the two copies of the libraries are located in unique locations sufficient to avoid any issues that may arise due to ambiguity or other linking errors? I think clearly not.. but I'd like to hear from an expert on this.

Assuming the description above is what's causing the problem, will merely changing the names of the libraries to include say some version information, e.g., mylib_v1.so and mylib_v2.so provide a safeguard against ambiguity errors (underlying function/namespaces names being still identical)? I still think not.. but I am not sure this time. Assuming I am right, would changing the namespaces using some macro in my code to include version info in namespaces (e.g., namespace mystuff {} changed to namespace mystuff_v1) do the trick at least? Appreciate your insights.

NOTE: Surprisingly the ambiguity occurs only on Windows! Linux is able to handle the situation in second paragraph without any problems.

Answer 1

If the applications are uniquely only using one, and PATHs and LD_LIBRARY_PATHs are set so that they do not meet there is no clash. You can see that with the hundreds of similar msvcrt.dll files once distributed with the applications, until Microsoft sorted that out.

But still, your (slightly different) code may create or refer to global resources and here can be the collision. Sure the Windows variant doesn't use something globally named, and introduces different data structures here? (File to store standard settings, shared memory, ...). As this global stuff is mostly pretty system-dependent - maybe you do something on Windows you don't do on Linux ...