Repository navigation
Building with libc++ on Windows instead of MSVC STL #58123
Description
Activity
It seems that libc++ can be built using ClangCL: https://releases.llvm.org/19.1.0/projects/libcxx/docs/BuildingLibcxx.html#support-for-windows
It seems that libc++ can be built using ClangCL:
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
(this means that they likely need to do the switch as well due to incompatible ABI)
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.
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.
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).
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.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.
During the V8 13.6 upgrade we noticed a crash on Windows that's likely caused by a bug of the
std::unordered_mapimplementation 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