On Wed, 2 Sep 2026, Zhongteng Gui wrote:
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.
Yes, if there are known cases where some parts can be unused, it's
certainly simplest to just split the files.
I guess one could look at what ends up omitted if linking a small trivial
binary with -ffunction-sections -fdata-sections -Wl,--gc-sections, and
see if that should be split to separate 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?
I think #undef _FORTIFY_SOURCE can be reasonable, if there are known files
where it breaks things. But I wouldn't mind using #error to avoid building
in such potentially messy setups as well. I think placing the #error in
_mingw.h seems a bit too public, but on the other hand, many mingw-w64-crt
files don't include its internal.h, so it may be the simplest place for
it.
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.
Right, yes, this sounds like an MSYS2 quirk to me.
It might be better to explicit specify CFLAGS="-g -O2" though, to avoid,
for example, GitHub runner accidently defines an empty CFLAGS.
Not sure if we need to guard against such hypotheticals...
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
