On Tue, 23 Jun 2026, Kirill Makurin wrote:
I wanted to send these changes a month ago, but I ran into issues I described in my
"libc++ unconditionally uses _create_locale, _configthraedlocale and friends?"
message back in May.
I hoped to find time to fix those issues in libc++, but in the end these
changes were just laying around in my local git tree ever since. So, instead, I
simply modified them to keep exposing _configthreadlocale, _create_locale and
friends for msvcrt.dll, so we do not break libc++ builds and possibly some
other packages which use those functions unconditionally.
This really should be fixed in libc++, but I guess another time. It would be a
great help if anyone could look into fixing usage of these functions in libc++.
I would argue that there is nothing to be fixed in libc++. It's free to
choose its supported Windows versions, and requiring a version that
includes the necessary locale functionality seems perfectly reasonable
to me.
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.
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.)
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).
But dropping it from the CI, is not an option.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
