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 3rd 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. From: 'Bill Ticehurst' via v8-dev <[email protected]> Sent: Monday, March 16, 2020 2:32 PM To: v8-dev <[email protected]> Subject: Re: [v8-dev] Re: Building with MSVC 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 On Sunday, March 15, 2020 at 5:58:24 PM UTC-7, Chris Fischer wrote: 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. On Sunday, March 15, 2020 at 5:54:51 AM UTC-4, Ben Noordhuis wrote: On Sat, Mar 14, 2020 at 3:03 PM Chris Fischer <[email protected] <mailto:[email protected]> > 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. -- -- v8-dev mailing list [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com <https://groups.google.com/d/msgid/v8-dev/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com?utm_medium=email&utm_source=footer> . -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/007901d5fc61%24e1d2e620%24a578b260%24%40gmail.com.
