tree 6da56ac28dc8f6f6d86a59ea04de2f17ae47d9db
parent ddeabf05d80db0758708ec502a68def11b4f9591
author Christian Pfeiffer <cpfeiffer@live.de> 1510066967 +0100
committer Brad King <brad.king@kitware.com> 1510146652 -0500

Restore exclusion of "gcc_eh" from implicit link libraries

Since commit v3.9.0-rc1~148^2 (Do not assume GCC libs are linked by all
compilers, 2017-05-05) we no longer filter out all `gcc*` implicit link
libraries.  This allows mixing of gcc and non-gcc compilers across
languages.  However, this caused a subtle problem with how GCC makes
exception handling symbols available to linked binaries.

GCC (at least on MinGW) provides two different libraries with exception
handling symbols:

* gcc_s: A shared library with -fvisibility=default, used by -shared-libgcc.
* gcc_eh: A static library with -fvisibility=hidden, used by -static-libgcc.

The C compiler (on MinGW) defaults to -static-libgcc and uses gcc_eh.
The C++ compiler defaults to -shared-libgcc and uses gcc_s when linking
shared libraries and executables so that exceptions can propagate across
shared libraries [1].  When linking a mixed-language binary, the C++
compiler should be used along with its choice of gcc_s.  In this case
gcc_eh should not be added even though the C compiler implies it because
gcc_s supersedes it.

Since the above-mentioned change, CMake is adding gcc_eh to C++ link
lines that also contain C code on MinGW.  This causes both gcc_s and
gcc_eh to be used, which is incorrect.  We can fix this simply by
excluding gcc_eh from the C compiler's implicit link libraries.

[1] https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Link-Options.html#Link-Options

Fixes: #17436