Author Topic: GCC 4.1.2 available (now relocatable!)  (Read 56202 times)

Offline nfz

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: GCC 4.1.2 available (now relocatable!)
« Reply #60 on: March 15, 2007, 04:08:31 pm »
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.

I also built Ogre with gcc 4.2.0 using DWARF2 exception handling and yes the binaries are much smaller for both debug and release builds and execution speed is quite a bit better than 3.4.5 builds.  The Ogre demos showed between 10% to 30% speed improvement when using DWARF2 instead of sjlj.  As already mentioned there is a problem if you raise an exception inside a windows callback - a crash will occur.  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.




Offline TDragon

  • Lives here!
  • ****
  • Posts: 936
    • Twilight Dragon Media
Re: GCC 4.1.2 available (now relocatable!)
« Reply #61 on: March 15, 2007, 05:01:54 pm »
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?

Quote
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).
« Last Edit: March 15, 2007, 05:03:29 pm by TDragon »
http://tdm-gcc.tdragon.net/ - TDM-GCC compiler suite for Windows (GCC 5.1.0 2015-06-28, 32/64-bit, no extra DLLs)

Offline nenin

  • Multiple posting newcomer
  • *
  • Posts: 95
Re: GCC 4.1.2 available (now relocatable!)
« Reply #62 on: March 16, 2007, 12:11:10 am »
APROPOS, is it possible to use DWARF2 in mingw? I got messages like "Breakpoint pending"- and thats all.

Online stahta01

  • Lives here!
  • ****
  • Posts: 6666
    • My Best Post
Re: GCC 4.1.2 available (now relocatable!)
« Reply #63 on: March 19, 2007, 12:11:33 am »
FYI:

Giovanni Bajo created installer for GCC 4.1.2

http://www.develer.com/oss/GccWinBinaries

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org