Request for Information: MSVC Support Status for V8 in Version 13

[Pradish]

Dear V8 Project Contributors,

I hope this message finds you well. First, I'd like to express my appreciation for your work on the V8 project. The engine has been a crucial component in many projects, including ours.

I'm reaching out to the community to gather some information about the current status of Microsoft Visual C++ (MSVC) support in V8, particularly for embedding V8 as a shared DLL or as static libraray. We've been using V8 in this configuration(shared dll)  and have some questions about its future support.

We've noticed that V8 version 13 has been released, but we couldn't find specific information in the commit tags or on V8 Blog regarding MSVC support depreciation,  We've also seen some discussions in the community suggesting potential changes to MSVC support.

If possible, we'd greatly appreciate any insights on the following:

1. What is the current status of MSVC support for V8 
2. Are there any plans to change MSVC support in future versions? If so, is there a general timeline available?
3. Are there any specific considerations in Version 13 that affect MSVC compatibility, especially for shared DLL usage?
4.  If changes to MSVC support are planned, are there recommended alternatives for projects using V8 as a shared DLL on Windows platforms?
5. Could you point us to any documentation or resources that might help us understand the project's direction regarding MSVC support?

We understand that as an open source project, plans can change, so any information you can provide would be incredibly helpful for our planning and potential contributions to the project.

Thank you for your time and for your continued work on V8.

Best regards,
Pradish

[Ben Noordhuis]

Not a V8 maintainer, just a downstream user, but I believe the
direction going forward can be summarized as: switch to clang-cl.

As to timelines: I don't believe upstream tests msvc any longer so you
might as well start now.

[Ben Ernst]

Has anyone collected any notes on switching to clang-cl? I need to do this as well.

Ben

--
--
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/CAHQurc_sq4x4MkaSqvh5xszZ3dgJwR01UdRKhS_uN6AHfUYO-w%40mail.gmail.com.

[J Decker]

On Sat, Oct 12, 2024 at 2:34 AM Pradish <prad...@gmail.com> wrote:

Dear V8 Project Contributors,

I hope this message finds you well. First, I'd like to express my appreciation for your work on the V8 project. The engine has been a crucial component in many projects, including ours.

I'm reaching out to the community to gather some information about the current status of Microsoft Visual C++ (MSVC) support in V8, particularly for embedding V8 as a shared DLL or as static libraray. We've been using V8 in this configuration(shared dll)  and have some questions about its future support.

We've noticed that V8 version 13 has been released, but we couldn't find specific information in the commit tags or on V8 Blog regarding MSVC support depreciation,  We've also seen some discussions in the community suggesting potential changes to MSVC support.

If possible, we'd greatly appreciate any insights on the following:

1. What is the current status of MSVC support for V8 
2. Are there any plans to change MSVC support in future versions? If so, is there a general timeline available?
3. Are there any specific considerations in Version 13 that affect MSVC compatibility, especially for shared DLL usage?
4.  If changes to MSVC support are planned, are there recommended alternatives for projects using V8 as a shared DLL on Windows platforms?
5. Could you point us to any documentation or resources that might help us understand the project's direction regarding MSVC support?

Enable clang for use instead... this isn't so bad... and then visual studio/msbuild still work the same, just MSVC becomes Clang-CL; and Clang-CL mostly understands cl.exe flags rather than gcc sort of flags

https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170

 

We understand that as an open source project, plans can change, so any information you can provide would be incredibly helpful for our planning and potential contributions to the project.

Thank you for your time and for your continued work on V8.

Best regards,
Pradish

--

--
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/dd80071e-a7f8-4e10-8e5a-912daa709538n%40googlegroups.com.

[Ben Ernst]

Is it necessary to use clang for the whole program?

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

[Ben Noordhuis]

On Wed, Oct 16, 2024 at 9:38 PM Ben Ernst <boi...@gmail.com> wrote:
>
> Is it necessary to use clang for the whole program?

In my (admittedly limited) testing clang-cl is ABI-compatible enough
that you can build the V8 .lib with clang-cl and link it against code
built with msvc.

I suppose you could still run into language constructs in the header
files that msvc doesn't understand or misparses.

[Pradish]

Thanks for the inputs, appreciate it immensely.

i tried to build the V8 using Clang but as a shared dll, though the build was successful without any issues. but when i tried to link the dll and headers it generated few compiler errors

Based on the suggestions, we started using clang to build V8 on windows, but there is a problem, the V8 uses the Chromium's implementation of the STL, so when importing the header files in windows, we get the linker errors , because windows uses its own version of STL.

class std::__Cr::unique_ptr<class v8::Platform,struct std::__Cr::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::__Cr::unique_ptr<class v8::TracingController,struct std::__Cr::default_delete<class v8::TracingController> >,enum v8::platform::PriorityMode)

how do we fix this.

[Ben Noordhuis]

On Fri, Oct 18, 2024 at 5:20 AM Pradish <prad...@gmail.com> wrote:
>
> Thanks for the inputs, appreciate it immensely.
>
> i tried to build the V8 using Clang but as a shared dll, though the build was successful without any issues. but when i tried to link the dll and headers it generated few compiler errors
>
> Based on the suggestions, we started using clang to build V8 on windows, but there is a problem, the V8 uses the Chromium's implementation of the STL, so when importing the header files in windows, we get the linker errors , because windows uses its own version of STL.
>
> class std::__Cr::unique_ptr<class v8::Platform,struct std::__Cr::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::__Cr::unique_ptr<class v8::TracingController,struct std::__Cr::default_delete<class v8::TracingController> >,enum v8::platform::PriorityMode)
>
> how do we fix this.

Pass use_custom_libcxx=false to tools/mb/mb.py (assuming that is what
you're using to create the build config) and rebuild.

[Pradish]

i getting these linker errors

my args.gn is as follows:
declare_args() {
    v8_enable_tests = false  # Set default value if needed
    v8_compress_pointers = true # Set to true to enable pointer compression
    use_absl = true
}
is_component_build = true
is_debug = false
target_cpu = "x64"
v8_enable_sandbox = false
v8_enable_backtrace = true
v8_enable_disassembler = false
v8_enable_object_print = true
v8_enable_verify_heap = true
dcheck_always_on = false
use_custom_libcxx=false
v8_enable_i18n_support = false
v8_enable_object_print = true
v8_use_external_startup_data = true
treat_warnings_as_errors = false
is_clang = true
v8_enable_fast_torque = false  

[3/1788] LINK(DLL) third_party_abseil-cpp_absl.dll third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
FAILED: third_party_abseil-cpp_absl.dll third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe "/OUT:./third_party_abseil-cpp_absl.dll" /nologo -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\20\lib\windows "-libpath:../../../../../../Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.41.34120/ATLMFC/lib/x64" "-libpath:../../../../../../Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.41.34120/lib/x64" "-libpath:../../../../../../Program Files (x86)/Windows Kits/NETFXSDK/4.8/lib/um/x64" "-libpath:../../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/ucrt/x64" "-libpath:../../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/um/x64" /MACHINE:X64  "/IMPLIB:./third_party_abseil-cpp_absl.dll.lib" /DLL "/PDB:./third_party_abseil-cpp_absl.dll.pdb" "@./third_party_abseil-cpp_absl.dll.rsp"
lld-link: error: <root>: undefined symbol: public: __cdecl absl::Cord::Cord<class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>>, 0>(class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> &&)
lld-link: error: <root>: undefined symbol: public: void __cdecl absl::base_internal::AtomicHook<void (__cdecl *)(enum absl::LogSeverity, char const *, int, class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> const &)>::operator()<enum absl::LogSeverity, char const *const &, int, char const (&)[34]>(enum absl::LogSeverity &&, char const *const &, int &&, char const (&)[34]) const
lld-link: error: <root>: undefined symbol: public: void __cdecl absl::base_internal::AtomicHook<void (__cdecl *)(enum absl::LogSeverity, char const *, int, class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> const &)>::operator()<enum absl::LogSeverity, char const *const &, int, char const (&)[38]>(enum absl::LogSeverity &&, char const *const &, int &&, char const (&)[38]) const
lld-link: error: <root>: undefined symbol: public: void __cdecl absl::base_internal::AtomicHook<void (__cdecl *)(enum absl::LogSeverity, char const *, int, class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> const &)>::operator()<enum absl::LogSeverity, char const *const &, int, char const (&)[39]>(enum absl::LogSeverity &&, char const *const &, int &&, char const (&)[39]) const
lld-link: error: <root>: undefined symbol: private: class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>> __cdecl absl::cord_internal::CordRepBtree::AddData<1>(class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>, unsigned __int64)
lld-link: error: <root>: undefined symbol: private: static class absl::cord_internal::CordRepBtree * __cdecl absl::cord_internal::CordRepBtree::AddData<1>(class absl::cord_internal::CordRepBtree *, class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>, unsigned __int64)
lld-link: error: <root>: undefined symbol: private: class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>> __cdecl absl::cord_internal::CordRepBtree::AddData<0>(class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>, unsigned __int64)
lld-link: error: <root>: undefined symbol: private: static class absl::cord_internal::CordRepBtree * __cdecl absl::cord_internal::CordRepBtree::AddData<0>(class absl::cord_internal::CordRepBtree *, class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>, unsigned __int64)
lld-link: error: <root>: undefined symbol: public: void __cdecl absl::Cord::Append<class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>>, 0>(class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> &&)
lld-link: error: <root>: undefined symbol: void __cdecl absl::strings_internal::Base64EscapeInternal<class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>>>(unsigned char const *, unsigned __int64, class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>> *, bool, char const *)
lld-link: error: <root>: undefined symbol: void __cdecl absl::base_internal::CallOnceImpl<void (__cdecl &)(void)>(struct std::__Cr::atomic<unsigned int> *, enum absl::base_internal::SchedulingMode, void (__cdecl &)(void))
lld-link: error: <root>: undefined symbol: void __cdecl absl::base_internal::CallOnceImpl<void (__cdecl absl::flags_internal::FlagImpl::*)(void), class absl::flags_internal::FlagImpl *>(struct std::__Cr::atomic<unsigned int> *, enum absl::base_internal::SchedulingMode, void (__cdecl absl::flags_internal::FlagImpl::*&&)(void), class absl::flags_internal::FlagImpl *&&)
lld-link: error: <root>: undefined symbol: private: static bool __cdecl absl::Condition::CastAndCallFunction<struct std::__Cr::atomic<bool> const>(class absl::Condition const *)
lld-link: error: <root>: undefined symbol: private: void __cdecl absl::log_internal::LogMessage::CopyToEncodedBuffer<1>(class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>)
lld-link: error: <root>: undefined symbol: private: void __cdecl absl::log_internal::LogMessage::CopyToEncodedBuffer<0>(class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>)
lld-link: error: <root>: undefined symbol: private: static bool __cdecl absl::str_format_internal::FormatArgImpl::Dispatch<class std::__Cr::basic_string<char, struct std::__Cr::char_traits<char>, class std::__Cr::allocator<char>>>(union absl::str_format_internal::FormatArgImpl::Data, class absl::str_format_internal::FormatConversionSpecImpl, void *)
lld-link: error: <root>: undefined symbol: private: static bool __cdecl absl::str_format_internal::FormatArgImpl::Dispatch<class std::__Cr::basic_string<wchar_t, struct std::__Cr::char_traits<wchar_t>, class std::__Cr::allocator<wchar_t>>>(union absl::str_format_internal::FormatArgImpl::Data, class absl::str_format_internal::FormatConversionSpecImpl, void *)
lld-link: error: <root>: undefined symbol: private: static bool __cdecl absl::str_format_internal::FormatArgImpl::Dispatch<class std::__Cr::basic_string_view<char, struct std::__Cr::char_traits<char>>>(union absl::str_format_internal::FormatArgImpl::Data, class absl::str_format_internal::FormatConversionSpecImpl, void *)
lld-link: error: <root>: undefined symbol: private: static bool __cdecl absl::str_format_internal::FormatArgImpl::Dispatch<class std::__Cr::basic_string_view<wchar_t, struct std::__Cr::char_traits<wchar_t>>>(union absl::str_format_internal::FormatArgImpl::Data, class absl::str_format_internal::FormatConversionSpecImpl, void *)
lld-link: error: <root>: undefined symbol: private: class absl::LogSink *& __cdecl absl::inlined_vector_internal::Storage<class absl::LogSink *, 16, class std::__Cr::allocator<class absl::LogSink *>>::EmplaceBackSlow<class absl::LogSink *const &>(class absl::LogSink *const &)
lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to see all errors)

[Ion Filipski]

> you can build the V8 .lib 

I've tried different ways of building v8, particularly playing with these settings

v8_static_library
is_component_build

v8_monolithic

None of them generated V8.lib. Other libraries like v8_base also not generated. So, what exactly is the way to create generate V8.lib?

[Pradish]

in the command line are you setting this argument ?  this will create the v8_monolith.lib the static library 

ninja -C out.gn/x64.release v8_monolith

i have used the following in my args.gn
is_component_build = false

is_debug = false
target_cpu = "x64"

use_custom_libcxx = false
v8_monolithic = true
v8_use_external_startup_data = false
is_clang = true

--

--
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 visit https://groups.google.com/d/msgid/v8-users/e0eb81b3-1742-4aaf-ad67-791353748ca3n%40googlegroups.com.

[Ion Filipski]

Hi, it worked and rebuilt v8_monolith.lib only. But it was on subdirectory obj. And it probably always was there, but I haven't noticed it, because it was in obj subdirectory.

Other libraries that were there before were

v8_libbase.lib
v8_libplatform.lib
wee8.lib

For debug version goes mostly the same.

Please disregard the previous message, it has small, but significative difference.

Thanks

[Pradish]

v8_monolith.lib is a self-contained and doesn't require linking with other v8 libraries
it includes all components (v8_libbase,v8_libplatform, v8_init.lib ..etc) 

To view this discussion visit https://groups.google.com/d/msgid/v8-users/3ecc2aa3-5274-4570-b2f5-279694ff35edn%40googlegroups.com.

[Justin Ferguson]

Hello,

I just wanted to add that I successfully compiled v8 today on Windows with clang-cl. I also tested the hello world sample, which worked.

I used the following config:

is_debug = false
target_cpu = "x64"
use_custom_libcxx = false
v8_monolithic = true
v8_use_external_startup_data = false
is_clang = true

And I had to add a line to build/config/win/BUILD.gn to silence c++20 deprecation warnings (which are treated as errors), specifically I added:

cflags += [ "/D_SILENCE_ALL_CXX20_DEPRECATION_WARNINGS" ]

at line 95 (other places would work as well).

Finally, in Visual Studio, I added the include directory and the obj directory to their respective places, switched the linker to /MT and linked to v8_monolith.lib
dbghelp.lib
Winmm.lib

Note that when I tried using libplatform or libbase I got errors, but v8_monolith alone is sufficient. I tried compiling without dbghelp.lib and winmm.lib but got errors relating to unresolved symbols that went away when I put them back in (there is nothing in the project except the .cpp file that I copy/pasted from the hello world sample).

[Ion Filipski]

Thanks, it worked with both, clang and msvc.