A quick scan of CMake source code shows that we don't have any references to gcc_eh anywhere. I way this could be occurring is through CMake detection of the implicit libraries that a compiler requires for each language. In particular it could be that C code for mingw by default uses gcc_eh while C++ doesn't. The culprit could also be a FindPackage* you are using.
On Wed, Aug 23, 2017 at 4:55 AM, Arne Kjetil Andersen <oel...@gmail.com> wrote: > Greetings. > > I'm a developer on a fairly large project where I'm using CMake version > 3.9.1 > > I primarily work on linux, but also cross compiles for windows using > Mingw-w64 on my linux box. > > 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. > > 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. > > So investigating some more I took a look at the linklibs.rsp file generated > for that particular test executable, and noticed this entry: > -lgcc_eh -lgcc_eh > > (yes it's twice, but that is not the issue, although that might be a cmake > bug?). > (also note - this option is also present for the 64 bit build files for > mingw-w64, but there it works as expected). > > 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. > > 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. > > 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? > > 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? > > I should probably also mention that the 32 bit version of Mingw-w64 uses the > sjlj exception handling mechanism. > > 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. > > Thanks for any input on this matter, and please let me know if attaching > CMakeOutput.log or other files would be beneficial. > > Best Regards, > Arne Kjetil Andersen > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake