...you're right, it should work out of the box. The strange thing is I pointed ogremain.lib build to use the freetype2 that I built myself... and it worked!
Cool
I'm really not all that familiar with the windows dev environment. I usually till now write console apps for things I do. So the whole windows dependency thing makes no sense to me right now. I don't really know what the difference in a multithreaded DLL and non threaded DLL is. I guess the multithreaded is reentrant, while the other is not. So I guess that means for MT DLL all sublibs compiled to it, they must be built reentrant too? Or maybe only the dynamic ones?
None of these things really required multithreading support as such. The main issue is the way the Win32 platform handles certain things. Each module (exe, dll, etc) get's its own heap, and obviously during the course of any program running, memory gets allocated and deallocated, and all this is normal, but Win32 does not like it when memory is allocated on one heap and then later deallocated on another (which can happen from something as innocent as modifying a std::string), the solution to this problem is to use a dll runtime, and ensure that all linked modules for an application are using the same one (this ensures that all allocations and deallocations of memory occur on the same heap - that of the runtime dll's).
But I am still hammering away on getting all of the plugin libraries to build; they don't work yet.
Hmmm... Could be those 2005 issues that someone mentioned on the Ogre forums. Not sure if anybody actually managed it in the end (you may well be the first!
).
