Unless we add a bot for the MSVC component release build, I think I'm going to give up on this. It just breaks too regularly.
I just got a fixed merged for an issue if you're just building the product binaries (see https://chromium-review.googlesource.com/c/v8/v8/+/2124886 ). I then went to do a full build, and there's a couple more breaks due to unresolved external symbols: *js-call-reducer-unittest.obj* and *redundancy-elimination-unittest.obj* both fail due to: *unresolved external symbol "__declspec(dllimport) public: static class v8::internal::Handle<class v8::internal::FeedbackMetadata> __cdecl v8::internal::FeedbackMetadata::New<class v8::internal::Isolate>(class v8::internal::Isolate *,class v8::internal::FeedbackVectorSpec const *)"* This appears to be due to changes in src/objects/feedback-vector.{h,cc} merged in March as part of https://chromium-review.googlesource.com/c/v8/v8/+/2066965 *node-cache-unittest.obj* has multiple failures related to " *v8::internal::compiler::NodeCache*". This appears to be due to https://chromium-review.googlesource.com/c/v8/v8/+/2087405 also merged in March which contains changes to src/compiler/node-cache.{h,cc} that removed the explicit template instantiation declarations/definitions of NodeCache<int32_t> and NodeCache<int64_t>. Both those change lists were written and reviewed by some of the best V8 devs there are, and still broken MSVC component release builds. Trying to keep this configuration working without a bot is a losing battle. - Bill On Friday, January 17, 2020 at 8:50:48 AM UTC-8, Bill Ticehurst wrote: > > I got the fix merged. Any by the time I sync'ed to master a built, it was > broken again already :-( This will likely be a pain to maintain. > > The additional fix ( > https://chromium-review.googlesource.com/c/v8/v8/+/2005528) has now also > been merged. (The V8 core team are really very good at prompt code reviews > and a pleasure to work with). > > Please grab it and test it while it works. I'll try and build it on a > regular basis to keep things humming along. > > To clarify: Release STATIC builds with MSVC work and usually do (Node.js > relies on these, and they are part of the V8 CI tests). This change fixes > Release DLL (or "component" in V8 parlance) builds. Debug DLL builds still > have issues, but that's a much bigger problem I'll look into as I have time. > > FYI: Below are the contents of my args.gn to build Release DLLs with > MSVC. Good luck! > > - Bill > > is_debug = false > target_cpu = "x64" > is_clang=false > is_component_build=true > > > On Monday, January 13, 2020 at 2:54:11 PM UTC-8, Ben Ernst wrote: >> >> Following with interest. >> >> Ben >> >> >> On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst <bill.t...@gmail.com> wrote: >> >>> 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-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/e738b2fd-3d7e-4684-8f45-9642b8e2c221%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-users/e738b2fd-3d7e-4684-8f45-9642b8e2c221%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/41227857-f416-40fa-b3ee-7f31c804fbb1%40googlegroups.com.
