On Saturday 04 July 2026 23:47:21 LIU Hao wrote: > 在 2026-7-4 21:57, Pali Rohár 写道: > > I rebased them on without the __mingw_init_ehandler changes. > > For the time being, I have pushed this series of changes to my fork. There's > still a pending issue: With your changes, the function > `__mingw_init_ehandler()` is now defined without `static`, so if it's > compiled anyway, it is likely to cause multiple definitions: > > https://github.com/lhmouse/mingw-w64/blob/7e42cfa20e597081ed6272aa71182cb82d3d3c13/mingw-w64-crt/crt/seh_signal_dispatcher.h#L16-L76 > > You get to decide how to deal with that function. At the moment there seems > to be no way to enable it; x86-64 always defines `__SEH__`, even when > compiling with `gcc -fno-exceptions -fno-unwind-tables > -fasynchronous-unwind-tables`.
You need to use -fno-asynchronous-unwind-tables (you are missing "no"). Or at least this switch is working with my gcc version. Maybe it is possible that gcc toolchain build with some other flags will not accept the -fno-asynchronous-unwind-tables flag (or ignores it). Anyway, I in other email I have proposed to remove the __mingw_init_ehandler code if the fixing it could not be accepted due to big maintenance issue. IMHO the current state of __mingw_init_ehandler is already maintenance issue, as seems to be that only me was able to compile mingw-w64 when that __mingw_init_ehandler code was enabled and was in use. So another argument for removal. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
