Re: [v8-users] Re: Building v8 shared library on windows

I've got the same issues. After I build on below args.gn, I got error building my projects. error LNK2019: unresolved external symbol "class std::unique_ptr > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::uniq

Re: [v8-users] Re: Building v8 shared library on windows

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

Re: [v8-users] Re: Building v8 shared library on windows

Im having same trouble here with VS2022 + v8 9.9, can someone please help? calling *v8::platform::NewDefaultPlatform()* generates unresolved external symbol error *this is the error message:* ErrorLNK2001unresolved external symbol "class std::unique_ptr > __cdecl v8::platform::NewDefaul

Re: [v8-users] Re: Building v8 shared library on windows

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

Re: [v8-users] Re: Building v8 shared library on windows

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

Re: [v8-users] Re: Building v8 shared library on windows

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

Re: [v8-users] Re: Building v8 shared library on windows

Following with interest. Ben On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst 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 shipp

Re: [v8-users] Re: Building v8 shared library on windows

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

RE: [v8-users] Re: Building v8 shared library on windows

;mailto:ivan.pizhe...@genesys.com> Sent: Friday, December 20, 2019 20:29 To: v8-users@googlegroups.com<mailto:v8-users@googlegroups.com> Subject: RE: [v8-users] Re: Building v8 shared library on windows Oh, that’s great. Thank you. I will try to apply similar patch locally to the 7.8.279.

Re: [v8-users] Re: Building v8 shared library on windows

Bill, Just wanted to say your work is appreciated. Anything interested parties can do to help keep msvc builds working? Willing to learn new skills to contribute, but could use pointing in a good direction. Ben On Sun, 22 Dec. 2019, 9:49 am Bill Ticehurst, wrote: > I spent a little more time on

Re: [v8-users] Re: Building v8 shared library on windows

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 ho

RE: [v8-users] Re: Building v8 shared library on windows

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

RE: [v8-users] Re: Building v8 shared library on windows

:43 To: v8-users<mailto:v8-users@googlegroups.com> Subject: Re: [v8-users] Re: Building v8 shared library on windows Just the header file for the public V8 API (https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18<https://chromium.googlesource.com/v8/v8.git/+/refs/

Re: [v8-users] Re: Building v8 shared library on windows

Just the header file for the public V8 API ( https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18) includes , , , , and from the C++ standard library. I'm unclear what they are all needed for, but I think it's safe to say mixing C++ standard libraries when building a

Re: [v8-users] Re: Building v8 shared library on windows

Unfortunately this issue transcends export naming. V8 seems to be embracing STL data types all over its API. By sheer luck std::unique_ptr is likely to work across STL implementations (at least when used without a stateful deleter), but other data types aren't so lucky. V8 already has a bunch o

Re: [v8-users] Re: Building v8 shared library on windows

Thank you for sharing that workaround Ivan, I believe I'm hitting the same problem, and your workaround might help me. On Thursday, 19 December 2019 05:28:41 UTC+10:30, Ivan Pizhenko wrote: > > That’s clear, the instruction under the link suggests to build V8 as > static library, which we alread

RE: [v8-users] Re: Building v8 shared library on windows

That’s clear, the instruction under the link suggests to build V8 as static library, which we already know to be working. But the point was to build and use V8 as DLL. Meanwhile, I’ve found following workaround: add 2 new custom functions to the libplatform, the first one returns normal pointer