MSVC will be unsupported after V8 version 13.0

[Hannes Payer]

Hi all,

V8 will follow Chromium's lead and will discontinue support for MSVC. To give projects time to adjust, we will stop support after V8 version 13.0 in September 2024. After that, we will remove the infrastructure bots and MSVC compatibility hacks in the code base.

Cheers,
Hannes

[Ben Ernst]

Ouch! We do use V8 on a live project compiled with MSVC. Thought it was worth throwing a comment out there, although I'm sure this isn't a decision that was taken lightly.

Cheers,

Ben

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CANaZRYwBjN3wR7MJEdk-fmkNPHWzJFd1RU1iC3SBA32MnD-uoA%40mail.gmail.com.

[J Decker]

On Monday, June 17, 2024 at 12:58:19 AM UTC-7 hpa...@chromium.org wrote:

Hi all,

V8 will follow Chromium's lead and will discontinue support for MSVC. To give projects time to adjust, we will stop support after V8 version 13.0 in September 2024. After that, we will remove the infrastructure bots and MSVC compatibility hacks in the code base.

 

Node uses MSVC to build on windows, which in turn uses V8; and I have a native plugin, which uses a node load hook, a little libuv, and a lot of v8; and I would miss VS Debugger... what do you use to build on windows?

I've found that the runtime for node/v8 and the native plugin need to match; I tried building using MinGW, but found incompatibilities between MinGW C++ and whatever VS C++ generated... 

Please don't? I understand there are costs, and I think I'm a less than quiet minority.

J

 

Cheers,
Hannes

[Hannes Payer]

Hi all,

We acknowledge that this is a change for everybody who is using MSVC. However there is a solution which hopefully works for many projects: clang-cl produces ABI-compatible output to MSVC. You can build v8 with clang-cl and link it to the code which is built with MSVC. The MSVC installer includes clang-cl as an install option.

Cheers,

Hannes

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CABexdQ4DUQrq74GTwtsnAhRO5WH1gN1Z9wZUr9J4aJLckWsEhw%40mail.gmail.com.

--

 

Hannes Payer |

V8 |

Google Germany GmbH |

Erika-Mann Str. 33, 80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Jean-Claude Monnin]

Hi Hannes,

Just a clarification: Does that mean only MSVC the compiler isn't supported anymore, but the Microsoft C++ Standard Library still works [1]? As you said, clang-cl is ABI compatible with MSVC, so I don't care which compiler is used to compiled v8, as long as I can link v8 with other code.

It's not always possible to use libc++ on Windows. In my case it's the precompiled Qt (possibly Qt works with libc++ on Windows, but I think it's unsupported). Mixing two huge libraries which require different C++ standard libraries wouldn't be fun. Additionally, I use closed source SDK's which mandate the Microsoft C++ standard library. I probably can't convince you if you want to support only libc++ on Windows, but I hope the Microsoft standard library is still supported so that v8 can be used in a standard Windows executable (fingers crossed).

Cheers,

Jean-Claude

[1]: https://learn.microsoft.com/en-us/cpp/standard-library/cpp-standard-library-overview?view=msvc-170

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKEgpyH%2B8HrOKLAxRW%2BU-S6d_n4NNOxw1e6uBGZqguqa%3D%3DS0Ww%40mail.gmail.com.

[Hannes Payer]

Hi Jean-Claude,

The preferred way would be to link both standard libraries. In your case, libc++ could be private to V8 and Microsoft standard library could be used for the rest. 

Cheers,

Hannes

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/8dd6a11c-f3ba-48dc-b19b-7787aee41d50%40app.fastmail.com.

[Dimitar Trendafilov]

Hi Hannes,

It is understandable that Chromium drives v8 development, but IMO quite a few of the decisions for V8 are taken ignoring the rests of its users (the embedders as the documentation calls us).

We have been embedding V8 since 6.4 and more than 6 years. This message has been brewing for the last 3-4 years, but I guess now is as good as ever to share my observations of where V8 is going as a whole.

And they are that V8 is becoming more and more unfriendly to the embedders. Some might say - hostile.
This is bad for us - the embedders and this is bad for the whole JavaScript community. V8 is state of the art VM, probably the best currently available, and it becomes less and less usable for everything outside of Chromium.
This means that eventually we'll have to settle for simpler, less efficient VMs, or use old - slower and insecure V8 versions or invest a lot of resources and create new JavaScript virtual machines.

A few examples:
1. The component build with MSVC has been broken (and fixed) quite a few times for the last 3-4 years. 
2. The component build using `clang-cl` is not really compatible with MSVC, due to the Zc:dllExportInlines- flag https://source.chromium.org/chromium/chromium/src/+/main:build/config/win/BUILD.gn;l=91-105; 

    and https://clang.llvm.org/docs/UsersManual.html#the-zc-dllexportinlines-option . Last time we tried removing the flag v8 didn't build. 

3. There are `std::vector`, `std::shared_pointer ` and `std::string` in the public APIs - forcing the embedded the use the same C++ STL (and lots of flags) as V8. Also uses the default allocators, which creates problems for projects where plain allocations are frowned upon. 
4. The tracing garbage collection for C++ objects now requires for the object to be allocated in a heap managed by v8. The embedder has to either deal with the circular references and leaks somehow or actually let v8 allocate his objects.

Probably one can link with the static clang v8 libraries, but then you have to build with the same standard library and compile with the same flags as V8. Example - V8 default configuration for Debug turns off iterator debugging, but that might be useful for the embedder code.  Again - iterator debugging can be enabled for V8, but at the cost for slower performance for code that I don't really expect to hit issues in. 

None of these are new, MSVC has been practically unsupported for years and embedders have been maintaining their own forks.
But with the complete removal these forks will become more and more expensive to maintain, until embedders just give up and move to other JavaScript runtimes.

Dimitar

[Dimitar Trendafilov]

Hi Hannes,

See my longer post, but how it will work to have both `std::` implementations for code like https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-cppgc.h;l=36-38

In the embedder code, `std::vector` comes from Microsoft, for V8 - from libc++ ?

Dimitar

[Jean-Claude Monnin]

Hi Hannes,

While the question hasn't been answered directly, I assume from the context of the answer that not only the MSVC compiler won't work anymore, but also compiling v8 against the Microsoft STL/Standard C+ library.

Given v8 uses the C++ standard library in it's public API, I don't see how your suggestion works. Can you provide more details?

Cheers,

Jean-Claude

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKEgpyF79yG5Y5CtUhOf7qT1fsC-xDPc9Kn9VidGnU28z4CFKw%40mail.gmail.com.

[Hannes Payer]

Hi all,

Continuing using the Microsoft standard library for V8 should be fine. However, this is not something we are testing. Note that the decision here is about deprecating MSVC not about standard library choice.

Cheers,

Hannes

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/03dc9930-dca9-42f9-a3a7-f0134dea89c4%40app.fastmail.com.