@@ -219,7 +219,31 @@ sources = [
219219 " !llvm/compiler-rt/lib/builtins/*xc3.c" ,
220220]
221221
222+ # ⭐ THE EXCEPTION MECHANISM FOLLOWS THE UNWINDER WE SHIP, NOT THE PLATFORM'S
223+ # DEFAULT.
224+ #
225+ # clang targeting this triple defines `__SEH__`, because that is what mingw uses
226+ # on this architecture — and libunwind's own public header then reaches for
227+ # `<windows.h>` and `<ntverp.h>`:
228+ #
229+ # unwind.h:22 → /usr/x86_64-w64-mingw32/include/windows.h
230+ # → crtdefs.h → corecrt.h:98 typedef redefinition
231+ #
232+ # ⚠️ That is the same class of failure as every other one on this target: a
233+ # vendor SDK reached because a platform macro was read as a statement about what
234+ # is underneath. Here the answer is a flag rather than an overlay, because the
235+ # question is genuinely a build decision: this program's unwinder is the one in
236+ # this package, and it reads DWARF tables — the same ones it reads on ELF and on
237+ # Mach-O.
238+ #
239+ # ⚠️ IT HAS TO REACH EVERY TRANSLATION UNIT IN THE GRAPH, for the reason
240+ # docs/13 records about `-fno-exceptions`: the model is recorded in a BMI, and a
241+ # dependency compiled one way cannot be imported by a unit compiled the other.
242+ # Stated here it covers this package; a consumer states it too, and mcpp
243+ # deciding it from the capability is the shape that would remove the repetition.
222244[target .'cfg(windows)' .build ]
245+ cxxflags = [" -fdwarf-exceptions" ]
246+ cflags = [" -fdwarf-exceptions" ]
223247sources = [
224248 " !llvm/libcxx/src/filesystem/int128_builtins.cpp" ,
225249 " llvm/compiler-rt/lib/builtins/*.c" ,
0 commit comments