I am provided with a third-party shared library file (name it libfoo.so, which I would like to associate with my application. I have no source code for libfoo.so, only its associated C ++ headers and as a result the binary is provided by a third party. libfoo.soHas several common bibliographic dependencies , in particular, several Boost libraries, such as libboost_thread.so.1.48. In addition, the list of dependencies is rather thin (essentially simple libstdc++.so.6).
Here's the catch: my application, which uses Boost heavily, is built on a newer version, v1.55. Therefore, if I try to link my application with the v1.55 libraries that it needs, as well as with the v1.48 libraries that are pulled in libfoo.so, I should run into problems with duplicate characters; that is not a starter. I could probably bring my application back to v1.48 with little work, but I would like this dependency not to deter me from changing versions of Boost in the future.
Is there some kind of intermediate product that I could create that is between libfoo.soand my application that separates Boost dependencies from each other? I found several similar SO questions, but none of them found to capture this particular situation; it is not specific to Boost per se, but instead refers to the development of a method for linking several versions of a shared library incompatible with ABI in a single application.
One approximate idea that I came across (which I'm not sure is even possible): is it possible to create a wrapper library that is around libfoo.soand statically put all its dependencies? If there was a way that I could take the libfoo.sovarious shared libraries to which it is linked and create a static library, say libfoowrapper.a, I could link this to my application directly (with the caveat that I am careful to leak any Boost material into wrapper library interface to protect against ABI incompatibility with two versions).
Is there a way to do something like this? At first I work on Unix-like platforms using gcc(Linux, MacOS); Windows (using Visual Studio) may be in the future.