The SDK was built and tested with the following:ĭownload the MinGW C++ Toolbox provided on the Ogre SF files site. What you need to provide that is not supplied in the SDK Source code and project files for 30 demos that you can compile and run as a confidence test of the SDK installation and to see what Ogre can do.All header files (*.h) for the libs/dll are included.API reference in the form of a windows compiled help (.chm).all the Ogre modules built for you ie the dll's and static archives.libstdc++ was rebuilt with wchar, wstring and wide stream to support wide strings so that Ogre 1.4.x could be built. Wchar, wstring and wide streams for unicode support don't work in the standard pre-built libstdc++ that comes with g++ 3.4.5. Libstdc++ was rebuilt with the configure option -enable-fully-dynamic-string so that strings are dynamically allocated using the RTL and can be passed across the dll boundry. Do a debug build of Ogre with libstdc++ and then run in gdb and you find out quickly that a crash occurs in OgrePlatform_d.dll after the config window closes when it tries to modify/deallocate a string passed to it from OgreMain.dll.Ī release build using libstdc++ 'seems' to run fine for simple Ogre demos but if you start passing a lot of Ogre strings across dll's in a more complicated app, the app starts to misbehave after a while and crashes occur. Ogre has several dll's and does pass strings and streams around. Because the static linking has each copy of libstdc++ managing its own strings and streams, passing a string/stream to another dll and then having it modified there will trash memory. This creates a problem when passing strings and any stream types across dll's. MingW will statically link libstdc++ (the library portion, not the STL) to each build ie each dll or exe. Why use a modified version of libstdc++ v3 with MingW? Ogre 1.2.x Dependencies and their version numbers.