[boost] Mixing different versions of Boost libs in a single process

Subject: [boost] Mixing different versions of Boost libs in a single process
From: Grund, Holger (Holger.Grund_at_[hidden])
Date: 2011-05-15 14:35:33

Hi,

I've been looking into how we can improve our own usage of Boost libraries and there's one thing that's been sticking out. We typically have often lots of components running in a single process. Many of these components are developed on different release schedules and while there's certainly demand to adopt later Boost versions, the logistics required to move all of these at the same time is a big headache.

Now, while I haven't seen any official word on it, I've always assumed there's no binary compatibility guarantees whatsoever between Boost versions. It's been my impression that there may be a few or even a lot of folks who would be happy to see binary compatibility, but it's unlikely to happen anytime soon.
 
So the next best thing would be the ability to mix different versions of Boost in a single process. Today, linkage names will be identical across versions, which is problematic for static libraries on Windows, and static libs and DSOs on Linux.

I remember discussion about making use of GCC's visibility attribute. This would certainly be a step in the right direction. I can't find the page I'm thinking of right now (pointers anyone?). Anyhow, what's the status of this?

Also there's BCP, which supports renaming namespaces. That's great, but I guess it could be even better -- e.g. on toolchains where we have inline namespaces or __attribute__((strong)). On Linux targets, symbol versioning via GNU LD version scripts might make things a bit better -- specifically, in that things gone wrong fail earlier and with better diagnostics.

Lastly, there's the problem of interop. Say libfoo built with Boost Version 1.40 provides an API like:

boost::some_class make_some_object();

If I want to use this in my component where I use Boost Version 1.50, how do I do it? I can think of a few of approaches, none of which really fully convinces me.

Consider the same API as a virtual member function, where no linkage name is involved (assuming boost::some_class changed in some relevant way). What to do there? And how to detect this in the first place? 

There might be other problems like having two different instances of a singleton for two libs in process, or something completely different I haven't thought of.

Is there any work going on in this area? Any interest?

Thanks!
-hg

Holger Grund, Vice President   
Morgan Stanley | MS Strats and Modeling   
25 Cabot Square | Canary Wharf | Floor 03   
London, E14 4QA   
Phone: [phone]   
Holger.Grund_at_[hidden]   

--------------------------------------------------------------------------
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.