Hi, I'm trying to track down a bug in my project which uses standard containers across shared objects. The program fails in std::_Rb_tree_decrement() after a call to std::map<std::string, std::list<boost::shared_ptr<...>>>::operator[]. I am using gcc version 4.0.3 and have added the -pthread and -shared-libgcc flags in order to make the executable and shared object use the same heap, but the program still fails. Am I missing a compiler/linker flag or do I need to override ::new and ::delete or provide a custom allocator? ~Cheers!

Moved to Unix forum.

In general, STL containers across DLL boundaries Just Don't Work. The main reason is that C++ template instantiation is incompatible with how dynamic symbol resolution works in all common operating systems. Any small difference in the headers used when object A was compiled, and object B was compiled, will lead to a binary incompatibility.

Pass a pure virtual interface across, instead. Or do what Microsoft did: define a whole new runtime and ABI (the .NET / CLR environment).

On which OS are your running this?

Under a POSIX OS, such as Linux, there is only a single free store in a process. In other words, a DSO (shared library) will always use the same free store (aka 'heap') as the rest of the program. There is no problem with object allocation across DSO boundaries. If there appears to be such a problem, it's probably a bug in your code and no compiler or liner swtches will solve that problem.

If this is on Windows under Cygwin (why else the -pthread?) then all bets are off.

I'm using Ubuntu and you're right, there was a bug in my code. Thank you all.
~Cheers