Im having same trouble here with VS2022 + v8 9.9 I copied the code from *v8\samples\hello-world.cc* calling *v8::platform::NewDefaultPlatform()* generates unresolved external symbol error however for the first two lines of hello-world.cc it calls *v8.dll.lib* works perfectly fine. i commented out platform related code, then it can be compiled but it has runtime exception due to platform is not correctly initialized. the problem only happens with *v8_libplatform.dll.lib *even it is located in same folder has same path as other libs.
seems VS2019 works fine? problem only happens with VS2022? *following is the error message:* Error LNK2001 unresolved external symbol "class std::unique_ptr<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >)" (?NewDefaultPlatform@platform@v8@@YA?AV?$unique_ptr@VPlatform@v8@@U?$default_delete@VPlatform@v8@@@std@@@std@@HW4IdleTaskSupport@12@W4InProcessStackDumping@12@V?$unique_ptr@VTracingController@v8@@U?$default_delete@VTracingController@v8@@@std@@@4@@Z) v8RunJS C:\Data\Code\v8RunJS\v8RunJS\main.obj 1 Can someone please help? On Tuesday, May 25, 2021 at 2:15:24 AM UTC+8 banslah...@gmail.com wrote: > 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/0bf558de-e1d5-4633-8fe6-073287b7a451n%40googlegroups.com.
