Repository navigation
Building with libc++ on Windows instead of MSVC STL #58123
Description
During the V8 13.6 upgrade we noticed a crash on Windows that's likely caused by a bug of the std::unordered_map implementation in MSVC STL #57753 (comment) - workaround in 4d7da6c. I am not entirely sure but it could come from the combination of ClangCL + MSVC STL, and MSVC STL might've been otherwise working with MSVC, though we've already dropped MSVC support so it's difficult to find out.
Since MSVC support has been dropped in V8, so does MSVC STL. Maybe we should consider switching to libc++ somehow (which is what the upstream supports on Windows), to prevent this kind of bug from happening again. I could see that it can be challenging for us (IIUC, Chromium/V8 solves this by just pulling the source code of libc++ and directly build against it) as well as for addons authors (this means that they likely need to do the switch as well due to incompatible ABI). But it does seem to be an idea worthy of more discussions.
The other way is to continue supporting ClangCL + MSVC STL, which can lead to more difficult-to-investigate bugs and the bugfix may not always be upstreamable if they get complicated enough. For now it may be manageable but it's difficult to tell how it'll pan out.
cc @nodejs/platform-windows @nodejs/build @StefanStojanovic @targos
Activity
targos commentedon May 5, 2025
It seems that libc++ can be built using ClangCL: https://releases.llvm.org/19.1.0/projects/libcxx/docs/BuildingLibcxx.html#support-for-windows
deepak1556 commentedon May 6, 2025
Not sure how clang-cl is pulled in today, but there is also the standalone script from chromium to download prebuilt clang binaries for a revision https://source.chromium.org/chromium/chromium/src/+/main:tools/clang/scripts/update.py;l=1 which could be parsed from https://chromium.googlesource.com/v8/v8.git/+/refs/heads/main/DEPS#311
Incase it is helpful, in Electron we disabled trivial abi clang extensions of shared_ptr (_LIBCPP_ABI_ENABLE_SHARED_PTR_TRIVIAL_ABI) and unique_ptr (_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI) that led to crashes for Nan based native modules, full background in linked blog post of this patch https://github.com/electron/electron/blob/main/patches/chromium/build_make_libcxx_abi_unstable_false_for_electron.patch. Ideal solution is for these addons to use the same libc++ build as the runtime or use the ABI stable N-API.
Flarna commentedon May 27, 2025
I think MSVC STL is more or less standard on windows similar as lib libstdc++ on linux.
Any native addon using C++ internally and interacting with some other shared object via a C++ API would likely run into serious challenges.
Unfortunately napi doesn't offer all v8 APIs as it's focus is vendor independent Javascript API and therefore not exposing the whole v8 API (e.g. profiler,...). So moving to napi is not always possible.
joyeecheung commentedon May 27, 2025
I think the choice between MSVC STL v.s. libc++ isn't just "which one is better", in the future it might be "MSVC STL simply no longer works with the latest V8 at all" (e.g. I cannot guarantee that we'd be able to come up with a hack like 4d7da6c if this happens again in the future, because MSVC STL is not supported by V8 and it's only Node.js that's supporting it). If that happened we might have to choose between building with libc++ and break some addons on Windows, or never update V8 again (e.g. if we couldn't find the aforementioned hack we probably would've delayed Node.js 24 indefinitely).
github-actions commentedon Apr 20, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon May 20, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.