Seems like MSVC component Release build is broken again. Anyone looking at this ?
Thanks, Himanshu On Wednesday, April 1, 2020 at 11:27:46 PM UTC+5:30 bil...@microsoft.com wrote: > 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/2f3cc763-3ff7-4e15-bb93-a1807b1a7c88n%40googlegroups.com.
