Being that this wouldn't be a "high priority" issue, the chance of getting it back-ported to older shipped branches is probably low. Sorry for those of you stuck on older builds. (Good news is, with v8 shipping every 6 weeks, you don't have to wait long until 'master' becomes 'legacy' :-) ).
I actually managed to simplify the changes somewhat by just suppressing a harmless MSVC warning that was being treated as an error. I've opened a CL against the tip of master at https://chromium-review.googlesource.com/c/v8/v8/+/1996157 . With this change you should be able to build a release DLL of V8 with MSVC. There was one linker error in the tests unfortunately I couldn't fix (yet) without breaking other platforms, so I had to comment that test out for MSVC DLL builds. I'll take another crack at it later. Debug builds of DLLs also have further issues on MSVC I haven't tackled yet. - Bill On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst wrote: > > I spent a little more time on this and pushed another commit to my fork of > the 8.0 branch (see comparison with upstream 8.0 at > https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1 > ). > > The tests now compile and pass with MSVC too now. For those following > along, this was how I ran the build/test. > > From the root folder, run the below to generate a x64 release build using > MSVC and building DLLs (assuming you're on Windows, obviously) > > * python tools\dev\v8gen.py -b x64.release msvc -- is_clang=false > is_component_build=true* > > Run the build, which should complete without error: > > * ninja -C out.gn/msvc <http://out.gn/msvc>* > > If you want to run the tests for good measure: > > * python tools/run-tests.py --outdir out.gn/msvc <http://out.gn/msvc>* > > You should find the resulting v8.dll, along with supporting dlls and .lib > files, in the .\out.gn\msvc directory. > > I haven't tested much beyond running the tests and doing a few ad-hoc D8 > experiments, and obviously this is unsupported/untested upstream (where the > are no bots building/testing/fuzzing this configuration). > > I'll tidy this up, open a CL, and see if this is something we can get > upstreamed, as several folks seem to want this option. Assuming V8/Google > doesn't want to run bots for this configuration but is happy to take fixes, > is would then be beholden on us (the V8 community) to keep it working. > (Personally, it seems to me like the only long-term sustainable solution > for cross-compiler support is a C-based API, similar to N-API for Node.js, > but I doubt there's much appetite for this currently). > > - Bill > > > On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >> >> Oh, that’s great. Thank you. I will try to apply similar patch locally to >> the 7.8.279.23, since I am allowed to use only “stable” versions of V8. >> >> - Ivan >> >> >> >> >> >> *From: *'Bill Ticehurst' via v8-users >> *Sent: *Friday, December 20, 2019 20:02 >> *To: *v8-users >> *Subject: *[v8-users] Re: Building v8 shared library on windows >> >> >> >> FWIW: I played around with the last night for a couple hours and got a >> release build working using a "component build" and MSVC. It was mostly >> moving some inline functions and adding some V8_EXPORT_PRIVATE statements >> (which effectively add the "__declspec(dllexport)" statements to expose >> functions across DLLs with MSVC). You can see the changes over the current >> V8 v8.0 branch at >> https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1 >> >> >> >> This is very rough code, hacking away at one build break at a time until >> it worked. I'll need to clean it up with a consistent approach before it >> would be ready for a CL. It also only works for the product binaries & D8 >> so far (i.e. build with "ninja -C out.gn\x64.release d8"), so I need to >> fix up the failures when building the test code (which means figuring out >> some of the subtlety in >> https://github.com/v8/v8/blob/master/src/base/export-template.h ). >> >> >> >> Bottom line: It seems fixable without major changes, and should be very >> low risk (as the V8_EXPORT_* macros effectively compile to nothing in >> static builds - which is what Chromium and Node.js use for release). >> >> >> >> - Bill >> >> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst >> wrote: >> >> I'm not clear on what is needed to fix this. The bug has been open quite >> a while (see https://bugs.chromium.org/p/v8/issues/detail?id=8791). >> >> On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote: >> >> Hi Bill, so what needs to be fixed to get DLL build (i.e. >> is_component_build=true) built successfully with MSVC compiler? >> >> I've recently run into the same linking issue with DLL build compiled >> using clang. And to say truth, it's weird that DLL build works only with >> clang. >> >> p.s. I cannot use prebuilt binaries from nuget and cannot use clang to >> build my app. Need to use strictly MSVC 2017. >> >> - Ivan >> >> >> On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote: >> >> To be clear, NuGet is a Microsoft run package manager, but "Microsoft" >> doesn't offer any pre-built V8 binaries. A user account named "pmed" >> created/uploaded that package, not a Microsoft account. >> >> >> >> If you are building V8 in a default manner with Clang as it appears, then >> you can't link it with a project you're building with the MSVC compiler. >> Those are two different compilers and C++ doesn't have a cross compiler >> stable ABI (especially if using "custom_libcxx", which means they are also >> using a different standard C++ library - V8 the Clang provided "libc++", >> and MSVC will use it's own). >> >> >> >> If you build V8 with Clang, you'll should build your project with Clang >> too (ideally using the same build toolchain - i.e. by updating the BUILD.gn >> file to include a target for your project - the doc at >> https://v8.dev/docs/embed details the Process and Shell sample apps >> which build via BUILD.gn and you can follow as an example). If you do >> decide to build V8 with MSVC, then as mentioned previously, "component >> build" isn't working currently, and you'll need to static link everything >> together ("is_component_build = false"), resulting in a large binary, >> rather than several V8 DLLs and a small application exe). >> >> >> >> - Bill >> >> >> On Tuesday, December 17, 2019 at 4:31:52 AM UTC-8, Stefan Wörthmüller >> wrote: >> >> Note that Microsoft also offers prebuild verrions of v8 via the package >> manager or direct to download. >> >> I.e. https://www.nuget.org/packages/v8-v140-x64/ click on "Download" at >> the right and rename the archive to zip. Works well for me. >> >> >> >> -- >> -- >> 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-u...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-users/a0a7c08b-7ff7-40cf-9104-021a97912018%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-users/a0a7c08b-7ff7-40cf-9104-021a97912018%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> > -- -- v8-users mailing list v8-users@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/e738b2fd-3d7e-4684-8f45-9642b8e2c221%40googlegroups.com.
