nfz: You've cleared a lot of things up with regard to Ogre and GCC for me at least; thanks.
gcc 4.1.x series is missing some MinGW patches that were applied to gcc 3.4.5. One of the important patches not accepted into the gcc 4 tree is allowing sjlj exceptions to cross dll boundries. So if you build Ogre from source with a MinGW build of gcc 4.1.x then as soon as Ogre or one of its dependencies dll raises an expection then the runtime will cause your program to terminate because the exception did not get handled inside the dll. WIth Ogre 1.4 the most likely spot for the first exception is with OIS initialization when it doesn't find a joystick attached. The demo code normally traps that exception and just continues on. It can happen earlier depending on ogre configuration. What I did was apply the missing patches to the 4.1 source to allow sjlj exceptions to cross the dll boundry. Note that the patches don't apply cleanly to the 4.1 source so you do have todo some fiddlin to get it to work. In the end I didn't find any performance benefits and builds were bigger.
Just to clear up the confusion: the Ogre 1.4RC2 SDK was built with gcc 3.4.5 using sjlj exception handling code. Note that 3.4.5 sjlj exception handling was modified to allow exceptions to cross dll boundries.
You can mix some of the pre-built Ogre dependencies with code compiled with gcc 4.1 if the dependencies are just straight c. But I found that if they are c++ then problems do occur. I just rebuilt all the dependencies with 4.1. Using the Ogre 1.4RC2 SDK with code compiled with gcc 4.1.2 will not work correctly due to the differences in how sjlj is being handled between code compiled with gcc 3.4.5 (the Ogre SDK) and code (your app) compiled with gcc 4.1.2.
Do you mean that the exceptions thrown from the (3.4.5+fully-dynamic-string) prebuilt Ogre SDK will not be caught only because GCC 4.1 series is missing the said patches from 3.4.5, or that there is some other unrelated incompatibility in the SJLJ exception backend between 3.4.5 and the 4.1 series? If only the former, then a build of GCC 4.1.2 using SJLJ exceptions and with these missing patches applied should in theory allow code compiled with it to correctly catch exceptions thrown from the prebuilt Ogre 1.4 SDK (3.4.5+fully-dynamic-string). Would you be able to provide a link to the mentioned patches to enable SJLJ exceptions across DLL boundaries?
The initial Ogre 1.4RC2 SDK was built with gcc 4.2.0 and the MinGW C++ Toolbox was going to be gcc 4.2.0 but I was still experiencing some strange behaviour in some of the demos and ran out of time to track down the source prior to release. For now the Ogre SDK will be built with gcc 3.4.5 with the modified libstdc++ until myself and others find solutions to the 4.2 problems.
Even if you do get Ogre and GCC 4.2 working together, there is still a LOT of code "in the wild" that was written to work with MinGW's official GCC 3.4.5 and would have issues with the GCC 4 series. As far as I'm concerned, it's better to distribute and recommend a version that is as close to MinGW's 3.4.5 as possible (like you are right now), for those who don't want to have to concern themselves with inter-version incompatibilities such as we've been discussing. You might then provide something from the GCC 4 series as a sleeker alternative for those who don't need backwards-compatibility (or are good at porting).
