<div dir="ltr"><div style="font-size:13.6px">Greetings.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">I'm a developer on a fairly large project where I'm using CMake version 3.9.1</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">I primarily work on linux, but also cross compiles for windows using Mingw-w64 on my linux box.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">I have encountered an issue which I'm having some trouble figuring out. Running through some of my tests where an exception is thrown (on purpose) the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls terminate even though there are try catch blocks. Now mind you, this all works fine on the native linux compiled version of my tests, and also the 64 bit windows version compiled with Mingw-w64-g++ version 7.1.1.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Going through all the projects CMakeLists.txt I could not find any reason for this behavior, but tried to add -fexceptions as a compiler option in the top most CMakeLists.txt file for the 32 bit mingw-w64 compiler. Unfortunately this made no difference.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">So investigating some more I took a look at the linklibs.rsp file generated for that particular test executable, and noticed this entry:</div><div style="font-size:13.6px">-lgcc_eh -lgcc_eh<br></div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">(yes it's twice, but that is not the issue, although that might be a cmake bug?).</div><div style="font-size:13.6px">(also note - this option is also present for the 64 bit build files for mingw-w64, but there it works as expected).</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Now, removing those two library link options from the linklibs.rsp file makes the 32 bit windows version of test application work as expected. I am not sure what libgcc_eh.a actually does (tried searching for some information, but had little luck actually figuring that out), but clearly it has something to do with exception handling.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Now I figured I would create a small minimal example that would reproduce this issue outside my projects source tree. So basically created a small program that throws an exception, and catches that. Created a CMakeLists.txt file with the same general options as my farily large project, and had cmake generate the build files for 32 bit mingw-w64. Inspecting the linklibs.rsp file I was surprised to see that "-lgcc_eh" were nowhere to be found, and as such the 32 bit version of this test worked fine.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">So, my question is, does anyone know under which circumstances cmake will add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake from doing so for the 32 bit mingw-w64 compiler?</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Also, maybe I'm going about this issue the wrong way, and that my findings mentioned above is not a good way of handling this. Or maybe this might be a bug with the 32 bit mingw-w64 compiler?</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">I should probably also mention that the 32 bit version of Mingw-w64 uses the sjlj exception handling mechanism.<br></div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Any help and pointers would be greatly appreciated - cause adding a step in the developer documentation to go into the linklibs.rsp file to remove -lgcc_eh is kind of a last resort.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Thanks for any input on this matter, and please let me know if attaching CMakeOutput.log or other files would be beneficial.</div><div style="font-size:13.6px"><br></div><div style="font-size:13.6px">Best Regards,</div><div style="font-size:13.6px">Arne Kjetil Andersen</div><div><br></div>
</div>