On 2026/09/02 17:12, Martin Storsjö wrote: > On Wed, 2 Sep 2026, Zhongteng Gui wrote: > >> Hi, I'd like to propose adding more testcases for mingw-w64-crt with >> different >> CFLAGS. I'm trying to enable `-O2`, `_FORTIFY_SOURCE=2` and >> `-fstack-protector-strong` when building mingw-w64-crt itself for MSYS2. > > Generally, adding testing for more build configurations may be useful - I've > also considered doing that for building mingw-w64-crt with > -ffunction-sections - > fdata-sections. (If doing that is entirely safe, we could even consider > defaulting to building with them enabled. But on the other hand, if we have > things split up enough into separate files, it shouldn't really gain us > anything > either.) >
I'm much agreed that `-ffunction-sections -fdata-sections -Wl,--gc-sections` is a more modern way to compile libraries instead of manually splitting each function into a seperated file. Though I'm a bit hestitate as this requires end users to always specify `-Wl,--gc-sections` so that only used symbols are picked from static libraries provided by us. Otherwise, IIRC, ld will default to bring in all sections in an object as long as any symbol from it is used, so we still can't avoid splitting files. >> Some regression (e.g. `-fstack-protector-strong` linking issue) is actually >> downstream (Rust) bug. However, some regression (e.g. `_FORTIFY_SOURCE=2` >> causes >> infinite loop in `__memcpy_chk` for Clang) is likely a bug in mingw-w64 >> itself. > > I'm not sure if I think it is reasonable to build mingw-w64-crt with > _FORTIFY_SOURCE=2, that can certainly lead to bugs like that. > > Many optimizations can transform user C code into a call for such a system > function, which causes infinite recursion, when you're actually trying to > implement that function. This is e.g. why we build mingw-w64-crt with > -fno-builtin. Yes, I agree this might be tricky. But maybe this can be solved by adding "#undef _FORTIFY_SOURCE" or something similar at the start of ssp sources. Or maybe you prefer to explicitly ban this usage, and adding a #error in _mingw.h if _FORTIFY_SOURCE and _CRTBLD is both defined? > >> Currently, GitHub CI only enables `-Werror`. And it's not clear whether >> `-O2` is >> enabled (there's some logic in `configure` that defaults to `-g -O2` or >> `-O2`, >> but I'm not sure whether they're effective). > > I'm quite sure that it is built with -O2; we do set CPPFLAGS, but as we don't > set CFLAGS, it should use the default values of "-g -O2". This is a bit tricky. For example, in MSYS2, CFLAGS is always defined and exported, even if '!buildflags' is specified, which results to an empty 'CFLAGS' and will hide the default `-O2`. But I agree this is not a bug in mingw-w64 itself. It might be better to explicit specify CFLAGS="-g -O2" though, to avoid, for example, GitHub runner accidently defines an empty CFLAGS. > >> BTW, I understand that some flags that are useful for downstream may not be >> applicable when compiling mingw-w64-crt itself (I suspect >> __USE_MINGW_ANSI_STDIO >> is one of these, and I'm not sure whether _FORTIFY_SOURCE is also one of >> these). > > __USE_MINGW_ANSI_STDIO shouldn't be relevant here, no; we hardcode building > with > -D__USE_MINGW_ANSI_STDIO=0 in mingw-w64-crt/Makefile.am. If you try to inject > another version of this define, it depends on whether it gets applied before > or > after our default. Yes, I'm aware of this. It might be better if this is documented. (Actually most documents of mingw-w64 are very old, but TBH it's usually less motivated to maintain documention then update code). > > In general, I'd say that most such user preferences aren't really relevant for > mingw-w64-crt - which is meant to be built in very specific ways. > > But testing with e.g. -ffunction-sections -fdata-sections (and -Wl,--gc- > sections) could be relevant. > > // Martin > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
