If you search for my last name on this or the v8-dev forum, you'll find a
lot of attempts at fixing this, and ultimately giving up. (e.g.
https://groups.google.com/forum/#!searchin/v8-users/ticehurst|sort:date/v8-users/mmwWxpb64_I/HtL-SI9wBgAJ
might
be the most relevant). Basically MSVC is not
, 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
Seeing as you state the error message is in VS2019, I'm assuming you are
trying to use these libraries once built from a Visual Studio/MSVC project?
If so, the issue may be that you are building V8 with one toolchain and
standard library (i.e. clang & libc++), and trying to consume with another
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 > wrote:
>
>> Being that this wouldn't be a &qu
ackled 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
rsions 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 ni
, 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 Pizhenk
lopers to keep all
>> public V8 APIs w/o any STL stuff for the sake of better integration with
>> different compilers, which with very high probability have different STL
>> implementations than libc++.
>>
>> - Ivan
>>
>>
>>
>>
>>
>> *
I believe this is still mostly correct - (some filenames might be out of
date, but should give you a general starting point). If you're already
building V8 successfully with MSVC, you should be able to skip down to the
"Embedding V8 into a custom application" part.
ng 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 binarie
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
Are you building with MSVC or Clang? The "component" build of V8 has some
issues with MSVC, but I believe should just work if using Clang.
Note: "component" build means a DLL build. Check that "is_component_build =
true" in your output folder's args.gn file, and then you should see v8*.dll
12 matches
Mail list logo
