<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 9:57 PM, Robert Maynard <span dir="ltr"><<a href="mailto:robert.maynard@kitware.com" target="_blank">robert.maynard@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A quick scan of CMake source code shows that we don't have any<br>
references to gcc_eh anywhere. I way this could be occurring is<br>
through CMake detection of the implicit libraries that a compiler<br>
requires for each language. In particular it could be that C code for<br>
mingw by default uses gcc_eh while C++ doesn't. The culprit could also<br>
be a FindPackage* you are using.<br></blockquote><div><br></div><div>Hi Robert and thanks for your reply. Yes I also did a scan of the cmake source code before sending the mail to the mailing list, and found no reference to gcc_eh. But I do find reference to that in the CMakeOutput.log file, and it seems to come from detection of implicit libraries. So based on this i started by removing all 3rd party libraries in my project and thought of adding one by one until the -lgcc_eh appeared in the linklibs.rsp, and you are right, adding proj.4 3rd party library to the build system seems to result in -lgcc_eh being added... Now to figure out how to prevent that from occurring in linklibs.rsp file for the test application that does not even use that particular 3rd party library.</div><div><br></div><div>Thanks again for pointing me in the right direction.</div><div><br></div><div>Best Regards,<br>Arne Kjetil Andersen<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Wed, Aug 23, 2017 at 4:55 AM, Arne Kjetil Andersen <<a href="mailto:oelbox@gmail.com">oelbox@gmail.com</a>> wrote:<br>
> Greetings.<br>
><br>
> I'm a developer on a fairly large project where I'm using CMake version<br>
> 3.9.1<br>
><br>
> I primarily work on linux, but also cross compiles for windows using<br>
> Mingw-w64 on my linux box.<br>
><br>
> I have encountered an issue which I'm having some trouble figuring out.<br>
> Running through some of my tests where an exception is thrown (on purpose)<br>
> the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls<br>
> terminate even though there are try catch blocks. Now mind you, this all<br>
> works fine on the native linux compiled version of my tests, and also the 64<br>
> bit windows version compiled with Mingw-w64-g++ version 7.1.1.<br>
><br>
> Going through all the projects CMakeLists.txt I could not find any reason<br>
> for this behavior, but tried to add -fexceptions as a compiler option in the<br>
> top most CMakeLists.txt file for the 32 bit mingw-w64 compiler.<br>
> Unfortunately this made no difference.<br>
><br>
> So investigating some more I took a look at the linklibs.rsp file generated<br>
> for that particular test executable, and noticed this entry:<br>
> -lgcc_eh -lgcc_eh<br>
><br>
> (yes it's twice, but that is not the issue, although that might be a cmake<br>
> bug?).<br>
> (also note - this option is also present for the 64 bit build files for<br>
> mingw-w64, but there it works as expected).<br>
><br>
> Now, removing those two library link options from the linklibs.rsp file<br>
> makes the 32 bit windows version of test application work as expected. I am<br>
> not sure what libgcc_eh.a actually does (tried searching for some<br>
> information, but had little luck actually figuring that out), but clearly it<br>
> has something to do with exception handling.<br>
><br>
> Now I figured I would create a small minimal example that would reproduce<br>
> this issue outside my projects source tree. So basically created a small<br>
> program that throws an exception, and catches that. Created a CMakeLists.txt<br>
> file with the same general options as my farily large project, and had cmake<br>
> generate the build files for 32 bit mingw-w64. Inspecting the linklibs.rsp<br>
> file I was surprised to see that "-lgcc_eh" were nowhere to be found, and as<br>
> such the 32 bit version of this test worked fine.<br>
><br>
> So, my question is, does anyone know under which circumstances cmake will<br>
> add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake from<br>
> doing so for the 32 bit mingw-w64 compiler?<br>
><br>
> Also, maybe I'm going about this issue the wrong way, and that my findings<br>
> mentioned above is not a good way of handling this. Or maybe this might be a<br>
> bug with the 32 bit mingw-w64 compiler?<br>
><br>
> I should probably also mention that the 32 bit version of Mingw-w64 uses the<br>
> sjlj exception handling mechanism.<br>
><br>
> Any help and pointers would be greatly appreciated - cause adding a step in<br>
> the developer documentation to go into the linklibs.rsp file to remove<br>
> -lgcc_eh is kind of a last resort.<br>
><br>
> Thanks for any input on this matter, and please let me know if attaching<br>
> CMakeOutput.log or other files would be beneficial.<br>
><br>
> Best Regards,<br>
> Arne Kjetil Andersen<br>
><br>
><br>
> --<br>
><br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at:<br>
> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br>
><br>
> Kitware offers various services to support the CMake community. For more<br>
> information on each offering, please visit:<br>
><br>
> CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
> CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
> CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">  A: Because it messes up the order in which people normally read text.<br>  Q: Why is top-posting such a bad thing?</div>
</div></div>