Martin Storsjö <[email protected]> wrote: > On Tue, 23 Jun 2026, Kirill Makurin wrote: >> I generally agree. The problem here is that we build libc++ as part of >> CI runs, and adding proper guards for those functions ends up breaking >> libc++ builds, which ultimately causes CI runs to fail. A solution would >> be to either drop some CI jobs for msvcrt.dll or update use of those >> functions on libc++. > > Dropping CI jobs for msvcrt.dll doesn't solve anything, at all. That just > ignores the problem, which then appears in my next build of llvm-mingw > with the latest mingw-w64 headers. > > The reason we have it in CI is to catch such issues already at the source, > rather than having to deal with breakage later.
Yes, that would be the case. In the version of the changes I sent, we still expose those functions for msvcrt.dll, so building both libc++ and llvm-mingw will continue to work. You can see that CI run for these changes passes. > Now ideally, sure, libc++ shouldn't be trying to use this function on > msvcrt.dll builds. > > However, speaking from experience with upstream libc++ development, > getting such a change through would be very hard, and a waste of > everybody's time. (There is very very little reviewer time available, and > spending it on things like this would be a waste - there are many much > more valuable things waiting for months for review.) That is unfortunate. Just note that _create_locale, _free_locale and _get_current_locale are available in msvcrt.dll since Windows 8, so you could define _WIN32_WINNT to 0x0602 or higher to expose them with original version of changes I wanted to send. However, _configthreadlocale is not available in msvcrt.dll at all and always replaced by a stab. > libc++ primarily only cares about platforms present in their own upstream > CI. There are mingw/ucrt builds there, but mingw/msvcrt builds results in > large numbers of libc++ testsuite failures. I did start out trying to > upstream such a CI build configuration without running tests, but they > indicated that if it is to be included, it should be running the tests too > - which would require annotating all those tests that they are expected to > be failing in mingw/msvcrt configurations. > > Without mingw/msvcrt configurations in CI, I doubt they would accept any > code complications specific for that configuration. > > Therefore, the pragmatic solution is to provide these symbols as stubs in > msvcrt.dll import libraries. If you want to hide the declarations from the > header, I'm not sure how to handle it in the most graceful way wrt > rebuilding libc++ (or building llvm-mingw overall). As I mentioned, the version of changes I sent still exposes them for msvcrt.dll exactly to support building libc++ and llvm-mingw. > But dropping it from the CI, is not an option. I absolutely agree. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
