WARNING: this SDK requires the use of the latest Code::Blocks from svn HEAD and will not work with Code::Blocks 1.0rc2. The MingW team has talked about supplying libstdc++.dll for many years (since 2000) but many roadblocks have prevented this. STLPorts license is very clear too, but the license for libstdc++ as a dll doesn't seem so clear.
It is used to build the dependencies and Ogre. STLPort 5.0.1 built out of the box with gcc 3.4.5 and was painless to setup up. Having used STLPort with vc6 back in 2003, I thought I would give it a try with MingW. And doing the modifications to build a dll were a pain in the butt. It does solve the problem, but there were still some issues. You could rebuild libstdc++ as a dll so that there is only one place where strings and streams are being managed. You'll quickly find that OgrePlatform_d.dll crashes 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. Do a debug build of Ogre with libstdc++ and then run it in gdb. 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 or 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 dll or exe built. Why use STLPort instead of libstdc++ v3 that comes with MingW?
0 kommentar(er)
