Today while trying to figure out why CI didn't pick up a mistake but
the build farm did, I learned a couple of interesting new-to-me facts
that are relevant to this thread:
1. When meson builds on "Linux-like" systems (by which it means GCC
or Clang detected, and MinGW is GCC), it jams -D_FILE_OFFSET_BITS=64
onto the command line[1].
2. When MinGW's headers see -D_FILE_OFFSET_BITS=64 it defines off_t
as large[2], along with related functions and structs.
That's a potential hazard to be aware of for our own code that
intercepts some but not all standard functions, and maybe different
ones in different branches, and it also doesn't match non-meson or
Visual Studio builds. We also already shipped recent releases that
way so it would be an ABI break to change it, if that matters.
Wow, what a lot of variations we have to handle with no coverage. I'm
coming around to your proposal Robert. We decide that it is OK to
back-patch freely, under a policy along the lines "we try to keep
stable branches working on the latest MinGW toolchain version only, as
a developer convenience". Even if it creates contradictions in
back-branches (using some stuff unguarded, even if other stuff is
guarded because it needed to be at the time). I'm not sure what
quorum is needed for such a decree, but from a verification point of
view, that's the effective reality already. An interested party would
need to show up with the resources to maintain another platform
variant; so yeah, why not let them do that, if something we back-patch
turns out to be a real problem for them?
[1] https://github.com/mesonbuild/meson/blob/853634a48da025c59eef70161dba0d150833f60d/mesonbuild/compilers.py#L2292
[2]
https://github.com/mingw-w64/mingw-w64/blob/8bcd5fc1a72c0b6da3147bf21a4a494c81d14fae/mingw-w64-headers/crt/_mingw_off_t.h#L24
