4

I have been provided a shared library file from a third party (call it libfoo.so that I would like to link into my application. I do not have the source code for libfoo.so, only its associated C++ headers and the resulting binary provided by the third party. libfoo.so has a few shared library dependencies, most notably a few Boost libraries, such as libboost_thread.so.1.48. Other than that, the dependency list is fairly thin (essentially just libstdc++.so.6).

Here's the catch: my application, which uses Boost heavily, is built against a newer version, v1.55. Therefore, if I try to link my application against the v1.55 libraries that it needs as well as the v1.48 libraries that libfoo.so pulls in, I'm bound to run into problems with duplicate symbols; that's a non-starter. I could probably roll my application back to v1.48 with a little work, but I'd like to prevent this one dependency from holding me back from changing Boost versions in the future.

Is there some kind of intermediate product that I could create that sits between libfoo.so and my application that would decouple the Boost dependencies from each other? I found a number of similar SO questions, but none that I could find that captured this particular situation; it's not Boost-specific per se, but instead relates to devising a way to link together multiple ABI-incompatible shared library versions into a single application.

One rough idea that I came up with (which I'm not sure is even possible): would it be possible to create a wrapper library that sits around libfoo.so and resolves all of its dependencies statically? If there was a way that I could take libfoo.so and the various shared libraries that it links to and create a static library, say libfoowrapper.a, I could link that into my application directly (with the caveat that I'm careful not to leak any Boost stuff into the wrapper library's interface, to guard against ABI incompatibilities with the two versions).

Is there any way to accomplish something like this? At first, I'm operating on Unix-like platforms using gcc (Linux, MacOS); Windows (using Visual Studio) could be in the future.

Jason R
  • 11,159
  • 6
  • 50
  • 81
  • Probably you should take a look at this thread: http://stackoverflow.com/questions/6302954/convert-shared-library-to-static-library – Miao ZhiCheng Apr 14 '14 at 13:26
  • For Boost specifically, you can [ask BCP to change the root namespace](http://stackoverflow.com/questions/2907882/using-concurrently-2-versions-of-boost) – Matthieu M. Apr 14 '14 at 13:33
  • @MatthieuM.: Thanks, I had considered that. I don't think that's a viable option because `libfoo.so` is already linked against the symbols in the normal `boost` namespace. If I tried to link it against a Boost v1.48 with a renamed namespace, wouldn't it fail to resolve those symbols at runtime? – Jason R Apr 14 '14 at 13:37
  • @JasonR: of course it would, however you can turn the problem around and change *your* code to compile/link with `boost_1_55` instead of `boost`. – Matthieu M. Apr 14 '14 at 13:40
  • @MatthieuM.: Good point. I'm not sure why I didn't think about that approach instead. That might be a good solution for this problem if there isn't anything non-Boost-specific that I could do. If there is a generic solution, I might prefer that, as I could have his happen again in the future with another dependency that isn't Boost. – Jason R Apr 14 '14 at 14:14
  • @JasonR: I agree, which is why it's not answer to your question. I just thought you might be interested in case the general problem is too tough to tackle :) – Matthieu M. Apr 14 '14 at 15:39

0 Answers0