Those functions have been problematic with mingw in the past and were marked as MOZ_ALWAYS_INLINE_EVEN_DEBUG. It's not enough for mingw clang builds that still occasionally emit those functions causing linker conflicts with libc++.a. It seems that's because they are marked as exported although they don't need to. Changing that fixes clang builds: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b5ff2559b18cd775b801a5a161cf6a3e207128a8&selectedJob=184999288 GCC builds also work with it: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f8640258f08067148096ba5118d8ecd69c44ebdf&selectedJob=184997176

Comment on attachment 8987951 [details] Bug 1471352 - Don't export functions from gcc_throw.h in mingw builds. https://reviewboard.mozilla.org/r/253232/#review259788 Thanks.

Pushed by jacek@codeweavers.com: https://hg.mozilla.org/integration/autoland/rev/ecd03215898d Don't export functions from gcc_throw.h in mingw builds. r=froydnj

Comment on attachment 8987951 [details] Bug 1471352 - Don't export functions from gcc_throw.h in mingw builds. [Approval Request Comment] This is one of several MinGW Build patches I'd like to land in esr60 for Tor. It will prevent them from carrying their own patches for the lifetime of esr60 and will enable us to keep the MinGW build functioning and know if/when/how it was broken by new commits into esr60. This commit only affects the MinGW build configuration, so it is low-risk.

Comment on attachment 8987951 [details] Bug 1471352 - Don't export functions from gcc_throw.h in mingw builds. Makes downstream maintenance easier for Tor. Approved for ESR 60.2.