id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
10581	Conflict when using boost::interprocess  objects when linking to 2 different boost versions	Yochai Timmer	Ion Gaztañaga	"'''Introduction''':
Boost interprocess directory and file naming has changed after boost 1.54.
Intreprocess communication does not work between version greater than 1.54 and lower than 1.54.
Related bug report: https://svn.boost.org/trac/boost/ticket/9767

'''The Scenario''':
Compile a .dll that uses some shared memory object from the boost::interprocess library with version 1.55. (Think of this as an external 3rd party dll which you have no control over).
Then make another project, using an older version of boost, lets say boost 1.51.
In the new project, open a shared memory object, then call a function from the dll that also opens a shared memory object.
This should have opened 2 shared memory objects, one with the 1.55 version and one with the 1.51 version.

The problem is that the second memory object will always fail (even if you change the order).

'''The Problem''':
Boost uses a singleton object to map the open interprocess memory objects.
Because of the versions mismatch, the first shared memory object that is created, also creates the map (And with it the file naming convention).

'''Solution''':
The singleton '''should''' just map the items, but use the functions according to the calling binary and compiled version of the caller.

'''Workaround''':
I've just changed the names in the singleton object.  
I figured you can't have redundancy if it's incompatible, so lets have a separate memory mapping.
In windows_intermodule_singleton.hpp changing the windows_semaphore_based_map named objects for the 1.55 version will keep the map separated."	Bugs	new	To Be Determined	interprocess	Boost 1.55.0	Problem