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
