Building with MSVC

[bil...@microsoft.com]

Is this still supported?

Trying to build the tip of master with 'is_clang = false' in args.gn (and various other attempted options) is giving lots of different warnings and failures, e.g.

cl : Command line warning D9002 : ignoring unknown option '/Zc:twoPhase'

.etc.

[501/1829] CXX obj/torque_generated_initializers/proxy-set-property-tq-csa.obj 

FAILED: obj/torque_generated_initializers/proxy-set-property-tq-csa.obj

.etc.

C:\src\v8\v8\src/codegen/code-stub-assembler.h(493): error C2059: syntax error: ','

.etc.

C:\src\v8\v8\src/objects/tagged-impl-inl.h(18): fatal error C1003: error count exceeds 100; stopping compilation

.etc.

It's the first time I've tried with MSVC, so may be doing something wrong. (I have no issues with the default clang-based builds on the same machine).

I can see from task manager and the log output it is using the right MSVC compiler (I tried with VS 2017 and VS 2019 installs), e.g.

> ninja -t msvc -e environment.x64 -- "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.22.27905\...

I see some of the V8 tryjobs build with MSVC (e.g. https://ci.chromium.org/p/v8/builders/try/v8_win64_msvc_compile_rel) and seem to be working, so if someone has the magic args.gn needed, I'd appreciate it.

Thanks,

 - Bill

[bil...@microsoft.com]

A colleague tracked it down to the CSA_ASSERT macro in code-stub-assembler.h failing in debug builds (looks like the tryjob only builds rel for MSVC).

This change 16 days ago seems to have broken it: https://chromium-review.googlesource.com/c/v8/v8/+/1693002 . If I check out the parent commit (0fd3766) I can build debug fine in MSVC (after one more trivial MSVC fix in a DCHECK in wasm-module-builder.cc). It still gives the "/Zc:twoPhase" compiler option warning, but hopefully that's benign.

I'll log a bug.

[Jakob Kummerow]

if someone has the magic args.gn needed, I'd appreciate it.

For the record, you can easily get any build bot's args.gn: click through to a specific build (in this case, e.g. https://ci.chromium.org/p/v8/builders/try/v8_win64_msvc_compile_rel/b8906608002392908144), and in the "Steps and Logs" section, look for "gn_args".

Is this still supported?

I'm not sure what the official policy is at the moment. I think at the very least, we would happily accept patches that maintain the MSVC build. As you have figured out, we have Release-mode buildbot coverage for it; I guess we assume that MSVC Debug builds are used and/or break rarely enough that spending bot resources on them is hard to justify.

--
--
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/61cdf5a4-a276-4fcb-9bd7-ed37f1c40d49%40googlegroups.com.

[Clemens Hammacher]

Note: This is being tracked as https://crbug.com/v8/9555 now. I am just landing a fix for this, and on the bug we are discussing whether we care enough about MSVC debug to add a bot to the waterfall.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3Q1cq4Vwzs3mS-bFjTHHKFbwSWzhhGwjqANA2V56E%3DvdQ%40mail.gmail.com.

--

Clemens Hammacher

Software Engineer

clem...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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.

[dim...@coherent-labs.com]

Hi Clemens,

I don't see any discussion in the bug  https://crbug.com/v8/9555 about the support for MSVC.
Is there a place, where we can vote or explain our use case for not breaking the usage of v8 from MSVC?

Best regards,
 Dimitar

To unsubscribe from this group and stop receiving emails from it, send an email to v8-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/61cdf5a4-a276-4fcb-9bd7-ed37f1c40d49%40googlegroups.com.

--
--
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-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3Q1cq4Vwzs3mS-bFjTHHKFbwSWzhhGwjqANA2V56E%3DvdQ%40mail.gmail.com.

[Clemens Backes]

On Tue, Feb 25, 2020 at 7:01 PM <dim...@coherent-labs.com> wrote:

Hi Clemens,

I don't see any discussion in the bug  https://crbug.com/v8/9555 about the support for MSVC.
Is there a place, where we can vote or explain our use case for not breaking the usage of v8 from MSVC?

You are right, the issue only raises the question but does not answer it.

This is a product decision that would best be made by +Michael Hablich.

I think this mailing list would actually be a good place to explain your use case. Alternatively, a v8 issue would also do, since depending on the outcome there will be infrastructure work to do on our side.

Cheers,

Clemens

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/04cceab7-c95c-4846-bfab-33ce84857ba0%40googlegroups.com.

--

Clemens Backes

[Ben Ernst]

Clemens, Dimitar,

This use case is very important to me also. I think there are a few threads in this group on the topic. For my part, I have complex application with many third party dependencies. Those dependencies do not support clang. So I can't compile my application with clang. I also call V8 code from several different first-party dynamically linked libraries within my application. Using a static linked build of V8 doesn't work in this situation. There is static data in V8 that ends up in multiple DLLs, and messes things up in horrible ways. I can re-architect to only link to V8 from one DLL to fix this. Since dynamic-linked V8 is no longer supported, I am slowly working on this, but it's a complex and painful task.

Cheers,

Ben Ernst

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/04cceab7-c95c-4846-bfab-33ce84857ba0%40googlegroups.com.

[Bill Ticehurst]

For what you describe, building a release DLL via MSVC should work fine (however Debug builds still have issues).

See https://groups.google.com/forum/#!topic/v8-users/cvFGONOg_BY and https://groups.google.com/forum/#!topic/v8-users/mmwWxpb64_I for prior discussions.

 - Bill

[Ben Ernst]

Thank you Bill, I appreciate you pointing that out. 

- Ben

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/7918eb46-8043-46f0-ab00-2b2bd8a26ba1%40googlegroups.com.

[dim...@coherent-labs.com]

Hi Bill,

Thanks for the pointers, however I got this error:

ninja -t msvc -e environment.x64 -- "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64/cl.exe" /nologo /showIncludes -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_ -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_RS2 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS -DV8_WIN64_UNWINDING_INFO -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_COMPRESS_POINTERS -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS -DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DBUILDING_V8_SHARED -DV8_COMPRESS_POINTERS -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_COMPRESS_POINTERS -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DUSING_V8_BASE_SHARED -I../.. -Igen -I../.. -Igen -I../../include -I../../third_party/zlib /Gy /FS /bigobj /utf-8 /Zc:sizedDealloc- /wd4117 /D__DATE__= /D__TIME__= /D__TIMESTAMP__= /W4 /WX /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503 /wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389 /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715 /MD /wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709 /wd4714 /wd4715 /wd4718 /wd4723 /wd4724 /wd4800 /wd4506 /O2 /Ob2 /Oy- /Zc:inline /Gw /TP /wd4577 /GR- /c ../../src/objects/js-objects.cc /Foobj/v8_base_without_compiler/js-objects.obj /Fd"obj/v8_base_without_compiler_cc.pdb"

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1264): error C2280: 'v8::internal::MemoryMeasurement::Request &v8::internal::MemoryMeasurement::Request::operator =(const v8::internal::MemoryMeasurement::Request &)': attempting to reference a deleted function

../..\src/heap/memory-measurement.h(43): note: compiler has generated 'v8::internal::MemoryMeasurement::Request::operator =' here

../..\src/heap/memory-measurement.h(43): note: 'v8::internal::MemoryMeasurement::Request &v8::internal::MemoryMeasurement::Request::operator =(const v8::internal::MemoryMeasurement::Request &)': function was implicitly deleted because a data member invokes a deleted or inaccessible function 'std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>> &std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>>::operator =(const std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>> &)'

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\memory(1913): note: 'std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>> &std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>>::operator =(const std::unique_ptr<v8::MeasureMemoryDelegate,std::default_delete<v8::MeasureMemoryDelegate>> &)': function was explicitly deleted

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1273): note: see reference to function template instantiation 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::_Assign_cast<v8::internal::MemoryMeasurement::Request&,_Iter>(_UIter,const _UIter)' being compiled

        with

        [

            _Iter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>,

            _UIter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>

        ]

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1273): note: see reference to function template instantiation 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::_Assign_cast<v8::internal::MemoryMeasurement::Request&,_Iter>(_UIter,const _UIter)' being compiled

        with

        [

            _Iter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>,

            _UIter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>

        ]

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1051): note: see reference to function template instantiation 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::assign<std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<_Ty>>,std::_Iterator_base0>,void>(_Iter,_Iter)' being compiled

        with

        [

            _Ty=v8::internal::MemoryMeasurement::Request,

            _Iter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>

        ]

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1051): note: see reference to function template instantiation 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::assign<std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<_Ty>>,std::_Iterator_base0>,void>(_Iter,_Iter)' being compiled

        with

        [

            _Ty=v8::internal::MemoryMeasurement::Request,

            _Iter=std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<v8::internal::MemoryMeasurement::Request>>,std::_Iterator_base0>

        ]

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1049): note: while compiling class template member function 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::_Copy_assign(const std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>> &,std::false_type)'

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\list(1065): note: see reference to function template instantiation 'void std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>::_Copy_assign(const std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>> &,std::false_type)' being compiled

../..\src/heap/memory-measurement.h(51): note: see reference to class template instantiation 'std::list<v8::internal::MemoryMeasurement::Request,std::allocator<v8::internal::MemoryMeasurement::Request>>' being compiled

../..\src/objects/objects.h(272): note: see reference to class template instantiation 'v8::internal::TaggedImpl<v8::internal::HeapObjectReferenceType::STRONG,v8::internal::Address>' being compiled

[204/903] CXX obj/v8_base_without_compiler/bytecode-label.obj

ninja: build stopped: subcommand failed.

when building the 8.1.307.16 tag (which according to git branch --contains has both the fixes) with the following args.gn

is_clang = false

is_component_build = true

is_debug = false

symbol_level = 1

target_cpu = "x64"

use_goma = false

v8_enable_backtrace = true

v8_enable_i18n_support = false

[Bill Ticehurst]

There was another break for a while, which I fixed in early Feb, and matches the error below. You probably need this change: https://chromium-review.googlesource.com/c/v8/v8/+/2042874

 - Bill

[Chris Fischer]

I'd like to chime in for continued support of MSVC (with build regression automated tests).  We embed V8 in a large project with many third party code components.  Many of these components are not available as source so building with CLANG is not viable.  We currently use V8 as a component build (DLL) but could also use V8 as a static library compiled with /MD.  In general, most of our third party software comes with these too variants (static & dynamic libraries with /MD runtime).

I'd be happy to help in contributing / maintaining MSVC support but would need a primer on contributing and and some contacts as sounding boards for feedback and brainstorming.

Chris Fischer

[Ben Noordhuis]

On Sat, Mar 14, 2020 at 3:03 PM Chris Fischer <cgfis...@gmail.com> wrote:
>
> I'd like to chime in for continued support of MSVC (with build regression automated tests). We embed V8 in a large project with many third party code components. Many of these components are not available as source so building with CLANG is not viable. We currently use V8 as a component build (DLL) but could also use V8 as a static library compiled with /MD. In general, most of our third party software comes with these too variants (static & dynamic libraries with /MD runtime).
>
> I'd be happy to help in contributing / maintaining MSVC support but would need a primer on contributing and and some contacts as sounding boards for feedback and brainstorming.
>
> Chris Fischer

I don't have a stake in this and I don't want to derail the
conversation but the clang-cl frontend is ABI-compatible with cl.exe
these days, isn't it? You don't even need to use it for all of your
project, just V8.

[Chris Fischer]

That was my thought as well.  However, when I successfully built V8 with CLANG and then tried to build our application with MSVC 2017 it failed in the link process with missing symbols.  Rebuilding the same version of V8 with MSVC (and fixing a few compiler errors and warnings for that to work) produced new binaries that resolved the linker errors.

[Bill Ticehurst]

I thought I'd posted before on why this is a problem currently, but can't find it. To summarize the major points:

1. Clang builds with flags MSVC doesn't support - specifically, /Zc:dllexportInlines- can cause issues with component builds. (As Clang won't export __declspec(dllexport) functions that have an inline definition, but MSVC may still try to import them - especially on debug builds where it inlines less). Maybe this is the missing symbols issues you hit, Chris?

2. While the compiler may try to be ABI compatible, the libc++ standard library from LLVM that V8 uses by default isn't compatible with the MSVC C++ standard runtime library, and some APIs expose C++ STL types.

Arguable both of these could be cleaned up in the codebase to where they aren't a problem, but right now they are. (#1 probably isn't an issue if building a static library to link in, but #2 still would be).

 - Bill

[Jakob Kummerow]

Is #2 not addressed by use_custom_libcxx = false in args.gn? At least on Linux, that causes the default system libstdc++ to be used.

--

--
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/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com.

[Bill Ticehurst]

Yes, but then you're doing a custom build anyway. I thought the goal was to take a regular V8 build and integrate it to a MSVC project.

Out of interest: How much test coverage does a "use_custom_libcxx = false" build have upstream?

To unsubscribe from this group and stop receiving emails from it, send an email to v8-...@googlegroups.com.

[Jakob Kummerow]

Yes, but then you're doing a custom build anyway. I thought the goal was to take a regular V8 build and integrate it to a MSVC project.

Oh, I thought the thread was about custom builds. (It's not like we're distributing any official builds -- one reason being that there are so many possible configurations.)

Out of interest: How much test coverage does a "use_custom_libcxx = false" build have upstream?

At a quick look, it's covered at least by this bot: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8885642278861891136/+/steps/build/0/steps/lookup_GN_args/0/logs/gn_args/0

There might well be more bots that cover it in the wider Chromium landscape.

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/a73110ff-d588-479a-8bbb-d96bba3148bb%40googlegroups.com.

[Chris Fischer]

Bill,

 

Thanks for your help.  Sorry for the delay in responding.  I was under pressure to get this resolved for our system.  I was able to do so but could not get the version 8.x code to work on Linux because we use CentOS 7 and AWS Linux1 which both have GLIBC 2.17 restrictions.  I ended up going with version 7.6 for Linux and had to “hack” a work-around for linker errors related to #2 from you e-mail.  Specifically the std::unique_ptr<v8::Platform> return value from the new default platform creation function.  On Windows I was able to compile 8.1 (stable chrome) with MSVC (VS 2019 v142) but had make 2 changes:

 

1. Modify the third_party/zlib/BUILD.gn configuration to rename the zlib.dll to something different (conflicted with other 3^rd party dependencies in our system).
2. Modify src/heap/memory-measurement.cc to provide explicit constructor and assignment move operations (also had to ! treat warnings as errors).

 

Not sure if these are worth pushing.  Advice?

 

What is the governing philosophy @V8 related to link & runtime compatibility with “native” compile environments for different operating systems?  It seems like Centos7 & RHEL7 are still very common in data centers and fertile grounds where embedded JavaScript solutions add value.  The GLIBC requirement for 2.18 seems onerous for embedders on those platforms.  Also, issue #2 (especially if there is no effort to correct or curtail API additions like that) will eventually force embedders to abandon V8 or convert their full stacks to use CLANG or at least libc++.  In our case, we have over a dozen open source or third party components that we need to update to change something like compiler platform or OS version.

--

--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/UBSd9g0c45E/unsubscribe.
To unsubscribe from this group and all its topics, 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/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com.

[Jakob Kummerow]

On Tue, Mar 17, 2020 at 2:42 PM Chris Fischer <cgfis...@gmail.com> wrote:

 

1. Modify the third_party/zlib/BUILD.gn configuration to rename the zlib.dll to something different (conflicted with other 3^rd party dependencies in our system).
2. Modify src/heap/memory-measurement.cc to provide explicit constructor and assignment move operations (also had to ! treat warnings as errors).

 

Not sure if these are worth pushing.  Advice?

I assume there's not much interest in upstreaming (1), as it sounds like an environment-specific issue, and the renaming might cause issues elsewhere.

(2) sounds more interesting, if you can describe more clearly when it's needed (we have an MSVC builder, why wasn't it a problem there?), and if it's still applicable to the current sources. See https://v8.dev/docs/contribute for the process.

Not treating warnings as errors is expected for non-standard toolchains. That said, if the errors are reasonable, I'd be happy to accept patches to fix them. (Sometimes specific compilers find things that are worth fixing; sometimes they just have weird issues that would require weird workarounds.)

What is the governing philosophy @V8 related to link & runtime compatibility with “native” compile environments for different operating systems?  It seems like Centos7 & RHEL7 are still very common in data centers and fertile grounds where embedded JavaScript solutions add value.  The GLIBC requirement for 2.18 seems onerous for embedders on those platforms.  Also, issue #2 (especially if there is no effort to correct or curtail API additions like that) will eventually force embedders to abandon V8 or convert their full stacks to use CLANG or at least libc++.  In our case, we have over a dozen open source or third party components that we need to update to change something like compiler platform or OS version.

The governing philosophy is that we are interested in keeping GCC/MSVC/libstdc++ builds working; nobody should be forced to use Clang or libc++. As I pointed out in my last email, we do have some ongoing test coverage. And we are happy to accept (reasonably non-intrusive) patches to improve compatibility (e.g. for GCC versions older or younger than what our bots test with).

Regarding versions, we don't break older distros on purpose, but e.g. at some point we decide "it's okay to use C++14 features in the code now", and then that means that we require system libraries that support that. RHEL/CentOS, especially still-supported-but-not-current versions, have historically often been quite far behind all other distros. In that particular case, linking against a custom libc++ might help -- just as much as linking against a custom (newer than what the system provides) libstdc++ would help.

I'm not sure we have spelled out an explicit policy somewhere, when in doubt we'd probably follow Google Chrome's requirements. Effectively I think it mostly boils down to "supported stable Debian / Ubuntu-LTS" as the minimum version. 

[Bill Ticehurst]

#2 was already fixed. I mentioned that commit earlier in this thread. See https://chromium-review.googlesource.com/c/v8/v8/+/2042874 

You could provide explicit members (I have a comment in that CL with a Gist to explain the problem which does exactly that - see https://gist.github.com/billti/bb83220ef70d2bd58e9889b83664b752 ). You can also just not export the class as it's not needed elsewhere, which is what my CL did.

 - Bill