Hello, Hi, I am developing a C++ library, which I distribute in binary form as a static library.

The implementation of my library uses Boost, but the interface does not, so I completely shield my users from the Boost dependency by linking the Boost object files that my implementation requires into the static library.

Suppose a client of my library uses Boost in their own code. When they link their executable, the linker now sees two copies of some Boost libraries: the copy in my static library, and their own copy that they are linking. It seems that the linker only keeps one of the two and discards the other.

If the Boost version that I linked into my static library is different from the Boost version my client uses, then one of my code and their code will be linked to a different version of Boost that the one it was compiled against, leading to a crash.

I suppose one way to rectify this problem would be for me to document what version of Boost libraries I compiled and linked against, and require that if my clients use Boost themselves, they use the same version. However, I dislike this solution for two reasons: 1) It exposes my library's dependence on Boost, which was meant to be an implementation detail. 2) It limits my clients to using a particular version of Boost. They may have good reasons for using an older (or newer!) version instead.

Le 05/09/12 01:41, Nathan Ridge a écrit : 3) it doesn't scales, as your client could be using other 3pp libraries that force to use a different version of Boost.

I would much prefer if the linker kept both copies of the Boost libraries in the executable, and each piece of code (mine and my client's) used whichever version of the libraries it was compiled against.

Can this be accomplished?

I see at least one possibility: rename the usage of the boost namespace in the Boost version you are using and in your own library, e.g. ridge_boost. But this doesn't work without troubles if there are visible symbols in Boost outside the boost namespace. Maybe such a tool can be shared in the Boost distributions once someone reaches to make it working. Has someone already tried this? A different and more complex problem appear if your library's interface uses Boost, as not only we need to ensure the linker symbols are unique, but also the files, the preprocessor macros, .... It would be great if someone has a solution to this problem too. Best, Vicente