Skip to content

Conversation

@FatihBAKIR
Copy link

Standard std::[io]fstream does not have a constructor from std::wstring, but from std::string or const wchar_t*. Microsoft STL has an extension that supports a std::wstring constructor, which the current code depends on. However, that extension does not exist in libc++ and therefore fails when trying to use libc++ with clang-cl on Windows.

This patch uses the standard-compliant constructor and builds with libc++.

https://en.cppreference.com/w/cpp/io/basic_ifstream/basic_ifstream.html
https://en.cppreference.com/w/cpp/io/basic_ifstream/basic_ofstream.html

Standard std::[io]fstream does not have a constructor from `std::wstring`, but from `std::string` or `const wchar_t*`. Microsoft STL has an extension that supports a `std::wstring` constructor, which the current code depends on. However, that extension does not exist in libc++ and therefore fails when trying to use libc++ with clang-cl on Windows.

This patch uses the standard-compliant constructor and builds with libc++.
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the best place for a fix would be in the definition of the USE_WSTRING_PATHS macro in support/path.h.

Does that sound right, @dschuff?

@dschuff
Copy link
Member

dschuff commented Nov 13, 2025

Yeah, USE_WSTRING_PATH is certainly the thing that controls whether we try to use std::wstring for paths. In addition to the constructors, there are also calls to ifstream::open() (e.g. in support/file.cpp) that basically have the same purpose (the purpose was to make sure that paths with non-ASCII are handled correctly, e.g. see test/lit/unicode-filenames.wast ). Are those calls also problematic for libc++?
And moreover, if we just disable USE_WSTRING_PATH on libc++ with windows, does that test still work? Mostly I'm just wondering whether the need to use std::wstring is a function of the c++ stdlib, or of the underlying OS.

More generally I am interested in having support for using libc++ with windows; we ship our emsdk binaries with libc++ on the other platforms, so it might be nice to do that for Windows too. How good is the support for that these days? How are you configuring your build?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants