it turns out makepkg already include ${MAKEPKG_CONF}.d/*.conf, which
results in the last alphabetically getting to set the variables. Rename
our directory without the .conf, so this pattern won't match it.
cmake for example doesn't use CPPFLAGS, so anything using cmake wont
get __USE_MINGW_ANSI_STDIO set, which is causing problems like
https://github.com/msys2/MINGW-packages/pull/21796
Instead move __USE_MINGW_ANSI_STDIO into CFLAGS and CXXFLAGS.
Uses "-Wp" because we already do that for _FORTIFY_SOURCE, not sure
if it helps with anything really, but why not.
See #4860
This is motivated by https://github.com/msys2/MINGW-packages/pull/20591
where flang v18 stopped supporting the -pipe flag which is passed to
it via LDFLAGS. v17 still supported it and it's not clear where and when
it was changed exactly.
Let's remove it from LDFLAGS because:
* it's not clear if -pipe actually does anything for linking
(it's still passed via CFLAGS/CXXFLAGS)
* other distros like Arch/Gentoo also only add it to CFLAGS/CXXFLAGS
* of the above flang issue
There are many cases where the extra memory is helpful and
with the type of software we package this hopefully shouldn't
lead to any problems.
Fixes#3283
In case a package has a configure check for say -mssse3 and then
enables it if the compiler supports it it would be passed to the compiler
before our CFLAGS, which currently has -mno-ssse3 (which seems to also disable
sse4 and above while at it). The code then assumes it's available but the compiler
fails.
While one could argue that we try to prevent ssse3+ being used in packages, there
are always exceptions like building sse4 code which dynamically gets executed.
So it's better we only enable machine options in CFLAGS and never disable them
Replace "-march=core2 -mno-ssse3" with the equivalent "-march=nocona -msahf".
Note that the GCC docs wrongly state that "nocona" doesn't include "CX16", while it does.
See https://github.com/msys2/MINGW-packages/pull/13651
There are some old AMD CPUs which run Win10 (somehow) but
don't have SSSE3 (not to be confused with SSE3), so explicitely
disable it. Both gcc and clang seem to understand this combination.