On Fri, Nov 15, 2024 at 1:53 AM Peter Eisentraut <pe...@eisentraut.org> wrote: > On 14.11.24 08:48, Thomas Munro wrote: > > The three MinGW environments we test today are using ucrt, and > > configure detects the symbol on all. Namely: fairwren > > (msys2/mingw64), the CI mingw64 task and the mingw cross-build that > > runs on Linux in the CI CompilerWarnings task. As far as I know these > > are the reasons for, and mechanism by which, we keep MinGW support > > working. We have no policy requiring arbitrary old MinGW systems > > work, and we wouldn't know anyway. > > Right. So I think we could unwind this in steps. First, remove the > configure test for _configthreadlocale() and all the associated #ifdefs > in the existing ecpg code. This seems totally safe, it would just leave > behind MinGW older than 2016 and MSVC older than 2015, the latter of > which is already the current threshold. > > Then the question whether we want to re-enable the error checking on > _configthreadlocale() that was reverted by 2cf91ccb, or at least > something similar. This should also be okay based on your description > of the different Windows runtimes. I think it would also be good to do > this to make sure this works before we employ _configthreadlocale() in > higher-stakes situations. > > I suggest doing these two steps as separate patches, so this doesn't get > confused between the various thread-related threads that want to > variously add or remove uses of this function.
OK, do you think these three patches tell the _configthreadlocale() story properly? (Then after that we can get back to getting rid of it...)
0001-Remove-configure-check-for-_configthreadlocale.patch
Description: Binary data
0002-Formally-require-ucrt-on-Windows.patch
Description: Binary data
0003-Revert-Blind-attempt-to-fix-_configthreadlocale-fail.patch
Description: Binary data
