Installing and Building STLshm
 
Prerequisites:
 
You’ll need to get and build the ACE library (http://www.cs.wustl.edu/~schmidt/ACE.html).   You don’t need to build the whole ACE distribution, just the libACE library.  As an optional component, you may also want to go and get the Loki library (http://loki-lib.sourceforge.net/).  I’m using the Loki libraries Factory implementation in the third example program that ships with STLshm, to show a functional way to make virtual methods and heterogenous containers usable when stored in shared memory.
 
Once you have these two built for your platform, you can then
1.    Install the ACE library per its instructions.  You only need to get the libACE library to build to then be able to make use of STLshm.
2.    Then install and build STLshm according to per-platform approach described later:
 
Posix (Linux, MacOS, Solaris, Unix in general)
 
1.    Download and untar the source into a directory (or pull from CVS.)
2.    Set the environment variable $ACE_ROOT to point to the directory where your  ACE distribtion lives.  i.e. $ACE_ROOT/ace has all the ace headers in it, and your libACE.so is in $ACE_ROOT/lib.
3.  Set the environment variable $LOKI_ROOT to point to the directory where your Loki library’s include directory is.  i.e. Loki headers will be included from $LOKI_ROOT/loki.
4.    ./configure
5.    make
6.    sudo make install (to copy the library/headers to /usr/local/ or other designated target)
 
The environment variables only need to be set during the build.  I admit that this approach is a stopgap while I learn how to create a configure script which can be told via command line options where the ACE and LOKI libraries are and whether the later is available.  (I’m still learning autoconf.)
 
The main STLshm library is compiled into the standard configure target directory (--prefix).  A couple of examples (tests) are also built to serve as examples and a means to validate the library on your specific platform.  These examples can help with determining if the STL implementation that you are using is compliant with needs of the shared memory allocator. (See below.)
 
Windows
 
1.    Coming soon.  (I need to create a VC++ project file for this.)
 
 
Requirements of the STL implementation
 
If you use explicitly specified virtual addresses when mapping shared memory into a process, then any STL implementation should be fine.  You will have to forever map that region at that address however, and can’t change the address without destroying and recreating the contents of the region.
 
If you want to allow processes to map the same shared memory region at different virtual addresses, then the STL library used with STLshm must use the pointer type defined by the allocator in its implementation.
 
Not all STL containers follow this convention.  The GNU version of the STL still does not conform to this.  In the Boost.interprocess library, that led to a discussion on changing the gcc STL to support allocator::pointer, which you can see here:  http://thread.gmane.org/gmane.comp.gcc.libstdc++.devel/12919
 
There are some STL libraries which may support this convention.  If you know of one, please e-mail me.  I intend to test the following:
 
1.    Microsoft STL (under windows), which I think is based on the Dinkum library.
2.    The Apache stdcxx, which is based on the RogueWave STL.  I believe this library adheres to this standard.