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 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:*
ErrorLNK2001unresolved external symbol "class std::unique_ptr > __cdecl
v8::platform::NewDefaultPlatform(int,enum
v8::platform::IdleTaskSupport,enum
v8::platform::InProcessStackDumping,class std::unique_ptr >)"
(?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)
v8RunJSC:\Data\Code\v8RunJS\v8RunJS\main.obj1
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 __cdecl
>> v8::internal::FeedbackMetadata::New(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 and NodeCache.
>>
>> 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
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
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::NewDefaultPlatform(int,enum
v8::platform::IdleTaskSupport,enum
v8::platform::InProcessStackDumping,class std::unique_ptr >)"
(?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)
v8RunJSC:\Data\Code\v8RunJS\v8RunJS\main.obj1
I use the code from *v8\samples\hello-world.cc*
seems VS2019 works fine? problem only happens with VS2022?
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 __cdecl
>> v8::internal::FeedbackMetadata::New(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 and NodeCache.
>>
>> 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
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
