Ok, I’ve worked through the STL/DLL combination problem and I have two possible solutions:
- Use an alternative STL implementation like STLport. This has the advantage of not requiring code changes but is likely to introduce different issues and would require any developers customising Ogre to get it too.
- Wrap the STL classes (as I have done with Ogre::String which is a wrapper for std::string) so that the implementation for accessing the internal STL class is always within the same DLL. This requires code changes but is not such a major risk as a completely new STL and is easier on developers using Ogre since it doesn’t require them to get the separate STL implementation.
I’m favouring the latter at the moment, especially because I know it works (my String wrapper prevented problems between Python and the DLL I was using for that previously).
The only problem with wrapping the more flexibly templated STL classes such as vector and map is that to localise the implementation I can’t ‘template-ise’ my own wrappers, because to do so would require putting implementations in header files, which would cause the same problems as now (the implementation would end up in any library that included the header). So instead I’ll have to identify just those STL classes that are causing the problem and define explicit non-templated wrappers for them, with the code which accesses the STL methods localised in the one DLL.
This problem prevented me from hitting my weekend deadline, but at least I know the library structure is working (all of the separate dlls are loading at the right time and I can debug into them, hence how I discovered this problem). I should be able to nail this in the next couple of evenings, then I’ll do another snapshot release.