Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Dan Elphick 
My suggested fix there doesn't seem to work MSVC non-component builds so
probably won't work for component builds either. I think
https://chromium-review.googlesource.com/c/v8/v8/+/1918249 should work.

On Fri, 15 Nov 2019 at 15:05, Dan Elphick  wrote:

> No worries. You're finding real bugs which clang/gcc which don't show up
> with clang/gcc because of the way they do dll import/exports.
>
> In this case there's a missing inline keyword at:
>
> https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?sq=package:chromium=0=150
>
> It should be:
> static *inline* bool IsKey
> 
> (ReadOnlyRoots
> 
> roots
> ,
> Object
> 
> k
> 
> );
>
> I'll upload a fix for this one, but I'm not likely to have time to spend
> on MSVC builds (since we don't officially support them), so probably won't
> do much else. If anything else is required, then please feel free to upload
> your own changes and I'll be happy to review them.
>
> Thanks,
> Dan
>
> On Fri, 15 Nov 2019 at 14:33, Ben Ernst  wrote:
>
>> Dan,
>> I resynced with your landed changes, and reverted 7186b6 as you
>> suggested. I encounter the error message below. As ever, I appreciate your
>> ongoing correspondence, I am sure it must be a painful process.
>> Ben
>>
>>  [exec] FAILED: obj/d8/async-hooks-wrapper.obj
>>  [exec] ninja -t msvc -e environment.x64 -- "C:\Program Files
>> (x86)\Microsoft Visual
>> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
>> /nologo /showIncludes -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD
>> -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE
>> -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS
>> -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL
>> -D_USING_V110_SDK71_ -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
>> -DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE
>> -DNTDDI_VERSION=NTDDI_WIN10_RS2 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00
>> -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
>> -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC
>> -DENABLE_HANDLE_ZAPPING -DV8_CONCURRENT_MARKING
>> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
>> -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
>> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
>> -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS
>> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS
>> -DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED
>> -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS
>> -DV8_IMMINENT_DEPRECATION_WARNINGS -DUSING_V8_BASE_SHARED
>> -DUSING_V8_PLATFORM_SHARED -I../.. -Igen -I../.. -Igen -I../../include
>> -Igen/include

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Dan Elphick 
No worries. You're finding real bugs which clang/gcc which don't show up
with clang/gcc because of the way they do dll import/exports.

In this case there's a missing inline keyword at:
https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?sq=package:chromium=0=150

It should be:
static *inline* bool IsKey

(ReadOnlyRoots

roots
,
Object

k

);

I'll upload a fix for this one, but I'm not likely to have time to spend on
MSVC builds (since we don't officially support them), so probably won't do
much else. If anything else is required, then please feel free to upload
your own changes and I'll be happy to review them.

Thanks,
Dan

On Fri, 15 Nov 2019 at 14:33, Ben Ernst  wrote:

> Dan,
> I resynced with your landed changes, and reverted 7186b6 as you suggested.
> I encounter the error message below. As ever, I appreciate your ongoing
> correspondence, I am sure it must be a painful process.
> Ben
>
>  [exec] FAILED: obj/d8/async-hooks-wrapper.obj
>  [exec] ninja -t msvc -e environment.x64 -- "C:\Program Files
> (x86)\Microsoft Visual
> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
> /nologo /showIncludes -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD
> -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE
> -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS
> -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL
> -D_USING_V110_SDK71_ -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
> -DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE
> -DNTDDI_VERSION=NTDDI_WIN10_RS2 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00
> -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
> -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC
> -DENABLE_HANDLE_ZAPPING -DV8_CONCURRENT_MARKING
> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
> -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
> -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS
> -DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED
> -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -DUSING_V8_BASE_SHARED
> -DUSING_V8_PLATFORM_SHARED -I../.. -Igen -I../.. -Igen -I../../include
> -Igen/include -I../../include /Gy /FS /bigobj /utf-8 /Zc:sizedDealloc-
> /wd4117 /D__DATE__= /D__TIME__= /D__TIMESTAMP__= /W4 /wd4091 /wd4127
> /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503 /wd4589 /wd4611
> /wd4100 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995
> /wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Ben Ernst 
Dan, 
I resynced with your landed changes, and reverted 7186b6 as you suggested. 
I encounter the error message below. As ever, I appreciate your ongoing 
correspondence, I am sure it must be a painful process.
Ben

 [exec] FAILED: obj/d8/async-hooks-wrapper.obj
 [exec] ninja -t msvc -e environment.x64 -- "C:\Program Files 
(x86)\Microsoft Visual 
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe" 
/nologo /showIncludes -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD 
-D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE 
-D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS 
-DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL 
-D_USING_V110_SDK71_ -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP 
-DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE 
-DNTDDI_VERSION=NTDDI_WIN10_RS2 -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 
-DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC 
-DENABLE_HANDLE_ZAPPING -DV8_CONCURRENT_MARKING 
-DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS 
-DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO 
-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH 
-DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS 
-DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS 
-DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED 
-DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS 
-DV8_IMMINENT_DEPRECATION_WARNINGS -DUSING_V8_BASE_SHARED 
-DUSING_V8_PLATFORM_SHARED -I../.. -Igen -I../.. -Igen -I../../include 
-Igen/include -I../../include /Gy /FS /bigobj /utf-8 /Zc:sizedDealloc- 
/wd4117 /D__DATE__= /D__TIME__= /D__TIMESTAMP__= /W4 /wd4091 /wd4127 
/wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503 /wd4589 /wd4611 
/wd4100 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995 
/wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221 
/wd4245 /wd4267 /wd4305 /wd4389 /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 
/wd4715 /Zi /MD /wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709 
/wd4714 /wd4715 /wd4718 /wd4723 /wd4724 /wd4800 /O2 /Ob2 /Oy- /Zc:inline 
/Gw /TP /wd4577 /GR- /c ../../src/d8/async-hooks-wrapper.cc 
/Foobj/d8/async-hooks-wrapper.obj /Fd"obj/d8_cc.pdb"
 [exec] C:\fd22cbe1\v8\src/objects/hash-table-inl.h(166): error C2491: 
'v8::internal::HashTable::IsKey': definition of dllimport 
function not allowed

On Saturday, 16 November 2019 00:42:59 UTC+10:30, Dan Elphick wrote:
>
> On 8.0, it looks like your errors are down to converting the return value 
> of ElementSizeLog2Of to uint8_t. Not sure why that's giving you an error 
> but triggering on the bots but you could try reverting 
> 7186b60147911736cdd385c787e6fd5e86052cb5 
>  locally and 
> see if that works.
>
> My changes are now landed so you should be able to revert those local 
> changes and resync.
>
> On Fri, 15 Nov 2019 at 13:56, Ben Ernst > 
> wrote:
>
>> Dan,
>> My build on "master" (8.0) failed, but probably for reasons unrelated to 
>> your changes.
>> I did my best to merge your changes to 7.9, I think I merged the changes 
>> correctly, but the compilation fails. It's possible that my merge is at 
>> fault though.
>> I've attached both logs in case they are useful.
>> Regards,
>> Ben
>>
>> On Friday, 15 November 2019 03:21:38 UTC+10:30, Clemens Hammacher wrote:
>>>
>>> FYI: There is an open bug about cleaning up utils.h 
>>> , and I worked a bit on that last Friday, 
>>> but did not get to split out the BitField class, and others. Thanks for 
>>> taking this over!
>>>
>>>
>>> On Thu, Nov 14, 2019 at 4:55 PM Dan Elphick  
>>> wrote:
>>>
 The utils.h header file is a bit of a mess. I've just uploaded (but not 
 yet committed) 
 https://chromium-review.googlesource.com/c/v8/v8/+/1916604, which 
 splits out the parts of that used by the problematic executable. I've 
 checked the preprocessor output on Linux and it looks like it's not 
 declaring any export symbols that aren't defined so that should work, but 
 I 
 can't easily test this on MSVC, so please let me know if you have any 
 further problems.

 This should be applied on top of the previous change and also it's 
 based on master so may not apply cleanly to 7.8.

 On Thu, 14 Nov 2019 at 12:41, Ben Ernst  wrote:

> Dan, I have attached the preprocessor output, following the same 
> directions as before. Many enthusiastic thanks for your help, I'm deeply 
> grateful. Ben. 
>
> On Thursday, 14 November 2019 22:53:52 UTC+10:30, Ben Ernst wrote:
>>
>> Dan, the patch very nearly did the trick, there's just one last 
>> unresolved external symbol. Ben.
>>
>>  [exec] [5/686] LINK bytecode_builtins_list_generator.exe 
>> bytecode_builtins_list_generator.exe.pdb
>>  [exec] FAILED:

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Clemens Backes 
FYI: There is an open bug about cleaning up utils.h
, and I worked a bit on that last Friday, but
did not get to split out the BitField class, and others. Thanks for taking
this over!


On Thu, Nov 14, 2019 at 4:55 PM Dan Elphick  wrote:

> The utils.h header file is a bit of a mess. I've just uploaded (but not
> yet committed) https://chromium-review.googlesource.com/c/v8/v8/+/1916604,
> which splits out the parts of that used by the problematic executable. I've
> checked the preprocessor output on Linux and it looks like it's not
> declaring any export symbols that aren't defined so that should work, but I
> can't easily test this on MSVC, so please let me know if you have any
> further problems.
>
> This should be applied on top of the previous change and also it's based
> on master so may not apply cleanly to 7.8.
>
> On Thu, 14 Nov 2019 at 12:41, Ben Ernst  wrote:
>
>> Dan, I have attached the preprocessor output, following the same
>> directions as before. Many enthusiastic thanks for your help, I'm deeply
>> grateful. Ben.
>>
>> On Thursday, 14 November 2019 22:53:52 UTC+10:30, Ben Ernst wrote:
>>>
>>> Dan, the patch very nearly did the trick, there's just one last
>>> unresolved external symbol. Ben.
>>>
>>>  [exec] [5/686] LINK bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec]
>>> C:/32cfab25/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>>> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
>>> /PDB:./bytecode_builtins_list_generator.exe.pdb
>>> @./bytecode_builtins_list_generator.exe.rsp
>>>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
>>> unresolved external symbol "public: void __cdecl
>>> v8::internal::VirtualMemory::Reset(void)" (?Reset@VirtualMemory
>>> @internal@v8@@QEAAXXZ) referenced in function "public: __cdecl
>>> v8::internal::VirtualMemory::VirtualMemory(class
>>> v8::internal::VirtualMemory &&)" (??0VirtualMemory@internal@v8@@QEAA@
>>> $$QEAV012@@Z)
>>>  [exec]
>>>  [exec]
>>>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
>>> symbol "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>>  [exec]
>>>  [exec]
>>>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
>>> "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>>  [exec]
>>>  [exec]
>>>  [exec] ./bytecode_builtins_list_generator.exe : fatal error
>>> LNK1120: 1 unresolved externals
>>>  [exec]
>>>  [exec]
>>>  [exec] [6/686] ACTION //:run_torque(//build/toolchain/win:x64)
>>>
>>>
>>>
>>> On Thursday, 14 November 2019 22:09:39 UTC+10:30, Dan Elphick wrote:

 So the problem is that utils.h includes include/v8.h. That declares
 things like IsolateFromNeverReadOnlySpaceObject, which is appearing in the
 preprocessor outputs as:

 __declspec(dllexport) internal::Isolate*
 IsolateFromNeverReadOnlySpaceObject(Address obj);

 It's marked as export because it's passing  -DBUILDING_V8_SHARED to the
 build command. Removing that is a little tricky, but the simpler way to fix
 is to rework the includes to avoid including v8.h:

 Here's a patch:

 diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
 index d9216f222a..a7386050d6 100644
 --- a/src/parsing/scanner.h
 +++ b/src/parsing/scanner.h
 @@ -10,6 +10,7 @@
  #include 
  #include 

 +#include "include/v8.h"
  #include "src/base/logging.h"
  #include "src/common/globals.h"
  #include "src/common/message-template.h"
 diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
 index f5e56ac951..0e15898f73 100644
 --- a/src/runtime/runtime.h
 +++ b/src/runtime/runtime.h
 @@ -7,6 +7,7 @@

  #include 

 +#include "include/v8.h"
  #include "src/base/platform/time.h"
  #include "src/common/globals.h"
  #include "src/objects/elements-kind.h"
 diff --git a/src/utils/utils.h b/src/utils/utils.h
 index 6f04ea63d3..8ba4e6bef7 100644
 --- a/src/utils/utils.h
 +++ b/src/utils/utils.h
 @@ -12,7 +12,6 @@
  #include 
  #include 

 -#include "include/v8.h"
  #include "src/base/bits.h"
  #include "src/base/compiler-specific.h"
  #include "src/base/logging.h"

 Please try that and see if it works and I'll upload up to master.


 On Thu, 14 Nov 2019 at 11:06, Ben Ernst  wrote:

> Dan,
>
> Yes, torque builds OK.
>
> I have attached the preprocessed output, zipped up. I hope that this
> tells you something.
>
> I tried building the

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick 
The utils.h header file is a bit of a mess. I've just uploaded (but not yet
committed) https://chromium-review.googlesource.com/c/v8/v8/+/1916604,
which splits out the parts of that used by the problematic executable. I've
checked the preprocessor output on Linux and it looks like it's not
declaring any export symbols that aren't defined so that should work, but I
can't easily test this on MSVC, so please let me know if you have any
further problems.

This should be applied on top of the previous change and also it's based on
master so may not apply cleanly to 7.8.

On Thu, 14 Nov 2019 at 12:41, Ben Ernst  wrote:

> Dan, I have attached the preprocessor output, following the same
> directions as before. Many enthusiastic thanks for your help, I'm deeply
> grateful. Ben.
>
> On Thursday, 14 November 2019 22:53:52 UTC+10:30, Ben Ernst wrote:
>>
>> Dan, the patch very nearly did the trick, there's just one last
>> unresolved external symbol. Ben.
>>
>>  [exec] [5/686] LINK bytecode_builtins_list_generator.exe
>> bytecode_builtins_list_generator.exe.pdb
>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>> bytecode_builtins_list_generator.exe.pdb
>>  [exec]
>> C:/32cfab25/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
>> /PDB:./bytecode_builtins_list_generator.exe.pdb
>> @./bytecode_builtins_list_generator.exe.rsp
>>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
>> unresolved external symbol "public: void __cdecl
>> v8::internal::VirtualMemory::Reset(void)" (?Reset@VirtualMemory
>> @internal@v8@@QEAAXXZ) referenced in function "public: __cdecl
>> v8::internal::VirtualMemory::VirtualMemory(class
>> v8::internal::VirtualMemory &&)" (??0VirtualMemory@internal@v8@@QEAA@
>> $$QEAV012@@Z)
>>  [exec]
>>  [exec]
>>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
>> symbol "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>  [exec]
>>  [exec]
>>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
>> "public: void __cdecl v8::internal::VirtualMemory::Reset(void)"
>> (?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
>>  [exec]
>>  [exec]
>>  [exec] ./bytecode_builtins_list_generator.exe : fatal error LNK1120:
>> 1 unresolved externals
>>  [exec]
>>  [exec]
>>  [exec] [6/686] ACTION //:run_torque(//build/toolchain/win:x64)
>>
>>
>>
>> On Thursday, 14 November 2019 22:09:39 UTC+10:30, Dan Elphick wrote:
>>>
>>> So the problem is that utils.h includes include/v8.h. That declares
>>> things like IsolateFromNeverReadOnlySpaceObject, which is appearing in the
>>> preprocessor outputs as:
>>>
>>> __declspec(dllexport) internal::Isolate*
>>> IsolateFromNeverReadOnlySpaceObject(Address obj);
>>>
>>> It's marked as export because it's passing  -DBUILDING_V8_SHARED to the
>>> build command. Removing that is a little tricky, but the simpler way to fix
>>> is to rework the includes to avoid including v8.h:
>>>
>>> Here's a patch:
>>>
>>> diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
>>> index d9216f222a..a7386050d6 100644
>>> --- a/src/parsing/scanner.h
>>> +++ b/src/parsing/scanner.h
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>
>>> +#include "include/v8.h"
>>>  #include "src/base/logging.h"
>>>  #include "src/common/globals.h"
>>>  #include "src/common/message-template.h"
>>> diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
>>> index f5e56ac951..0e15898f73 100644
>>> --- a/src/runtime/runtime.h
>>> +++ b/src/runtime/runtime.h
>>> @@ -7,6 +7,7 @@
>>>
>>>  #include 
>>>
>>> +#include "include/v8.h"
>>>  #include "src/base/platform/time.h"
>>>  #include "src/common/globals.h"
>>>  #include "src/objects/elements-kind.h"
>>> diff --git a/src/utils/utils.h b/src/utils/utils.h
>>> index 6f04ea63d3..8ba4e6bef7 100644
>>> --- a/src/utils/utils.h
>>> +++ b/src/utils/utils.h
>>> @@ -12,7 +12,6 @@
>>>  #include 
>>>  #include 
>>>
>>> -#include "include/v8.h"
>>>  #include "src/base/bits.h"
>>>  #include "src/base/compiler-specific.h"
>>>  #include "src/base/logging.h"
>>>
>>> Please try that and see if it works and I'll upload up to master.
>>>
>>>
>>> On Thu, 14 Nov 2019 at 11:06, Ben Ernst  wrote:
>>>
 Dan,

 Yes, torque builds OK.

 I have attached the preprocessed output, zipped up. I hope that this
 tells you something.

 I tried building the following versions of V8 (in addition to 7.8 I was
 building originally), they all have essentially the same problem.

 7.9.317.22
 7.7.299.15
 7.2.502.28

 Thank you in advance for any ideas.
 Ben

 On Thursday, 14 November 2019 20:47:56 UTC+10:30, Dan Elphick wrote:
>
> If instead of building everything, does torque build? e.g. ninja -C
>  torque. It

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Ben Ernst 
Dan, the patch very nearly did the trick, there's just one last unresolved 
external symbol. Ben.

 [exec] [5/686] LINK bytecode_builtins_list_generator.exe 
bytecode_builtins_list_generator.exe.pdb
 [exec] FAILED: bytecode_builtins_list_generator.exe 
bytecode_builtins_list_generator.exe.pdb
 [exec] 
C:/32cfab25/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe 
../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 
False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe 
/PDB:./bytecode_builtins_list_generator.exe.pdb 
@./bytecode_builtins_list_generator.exe.rsp
 [exec] generate-bytecodes-builtins-list.obj : error LNK2019: 
unresolved external symbol "public: void __cdecl 
v8::internal::VirtualMemory::Reset(void)" 
(?Reset@VirtualMemory@internal@v8@@QEAAXXZ) referenced in function "public: 
__cdecl v8::internal::VirtualMemory::VirtualMemory(class 
v8::internal::VirtualMemory &&)" 
(??0VirtualMemory@internal@v8@@QEAA@$$QEAV012@@Z)
 [exec]
 [exec]
 [exec] bytecode-operands.obj : error LNK2001: unresolved external 
symbol "public: void __cdecl v8::internal::VirtualMemory::Reset(void)" 
(?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
 [exec]
 [exec]
 [exec] bytecodes.obj : error LNK2001: unresolved external symbol 
"public: void __cdecl v8::internal::VirtualMemory::Reset(void)" 
(?Reset@VirtualMemory@internal@v8@@QEAAXXZ)
 [exec]
 [exec]
 [exec] ./bytecode_builtins_list_generator.exe : fatal error LNK1120: 1 
unresolved externals
 [exec]
 [exec]
 [exec] [6/686] ACTION //:run_torque(//build/toolchain/win:x64)



On Thursday, 14 November 2019 22:09:39 UTC+10:30, Dan Elphick wrote:
>
> So the problem is that utils.h includes include/v8.h. That declares things 
> like IsolateFromNeverReadOnlySpaceObject, which is appearing in the 
> preprocessor outputs as:
>
> __declspec(dllexport) internal::Isolate* 
> IsolateFromNeverReadOnlySpaceObject(Address obj);
>
> It's marked as export because it's passing  -DBUILDING_V8_SHARED to the 
> build command. Removing that is a little tricky, but the simpler way to fix 
> is to rework the includes to avoid including v8.h:
>
> Here's a patch:
>
> diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
> index d9216f222a..a7386050d6 100644
> --- a/src/parsing/scanner.h
> +++ b/src/parsing/scanner.h
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  
> +#include "include/v8.h"
>  #include "src/base/logging.h"
>  #include "src/common/globals.h"
>  #include "src/common/message-template.h"
> diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
> index f5e56ac951..0e15898f73 100644
> --- a/src/runtime/runtime.h
> +++ b/src/runtime/runtime.h
> @@ -7,6 +7,7 @@
>  
>  #include 
>  
> +#include "include/v8.h"
>  #include "src/base/platform/time.h"
>  #include "src/common/globals.h"
>  #include "src/objects/elements-kind.h"
> diff --git a/src/utils/utils.h b/src/utils/utils.h
> index 6f04ea63d3..8ba4e6bef7 100644
> --- a/src/utils/utils.h
> +++ b/src/utils/utils.h
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  
> -#include "include/v8.h"
>  #include "src/base/bits.h"
>  #include "src/base/compiler-specific.h"
>  #include "src/base/logging.h"
>
> Please try that and see if it works and I'll upload up to master.
>
>
> On Thu, 14 Nov 2019 at 11:06, Ben Ernst > 
> wrote:
>
>> Dan,
>>
>> Yes, torque builds OK.
>>
>> I have attached the preprocessed output, zipped up. I hope that this 
>> tells you something.
>>
>> I tried building the following versions of V8 (in addition to 7.8 I was 
>> building originally), they all have essentially the same problem.
>>
>> 7.9.317.22
>> 7.7.299.15
>> 7.2.502.28
>>
>> Thank you in advance for any ideas.
>> Ben
>>
>> On Thursday, 14 November 2019 20:47:56 UTC+10:30, Dan Elphick wrote:
>>>
>>> If instead of building everything, does torque build? e.g. ninja -C 
>>>  torque. It looks like it does from the log but just want to 
>>> check. It seems odd that it can build that one but not the other simpler 
>>> executable.
>>>
>>> Below  is the command line for building bytecode-operands.obj from your 
>>> log. It specifies only the single .cc which doesn't include very much at 
>>> all so I don't see how it would get those symbols. You could try adding the 
>>> /P option to cl.exe (
>>> https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019
>>>  
>>> )
>>>  
>>> and see what the preprocessed output is.
>>>
>>> ninja -t msvc -e environment.x64
>>> --
>>> "C:\Program Files (x86)\Microsoft Visual 
>>> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
>>> /nologo /showIncludes
>>> -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C 
>>> -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
>>>

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick 
So the problem is that utils.h includes include/v8.h. That declares things
like IsolateFromNeverReadOnlySpaceObject, which is appearing in the
preprocessor outputs as:

__declspec(dllexport) internal::Isolate*
IsolateFromNeverReadOnlySpaceObject(Address obj);

It's marked as export because it's passing  -DBUILDING_V8_SHARED to the
build command. Removing that is a little tricky, but the simpler way to fix
is to rework the includes to avoid including v8.h:

Here's a patch:

diff --git a/src/parsing/scanner.h b/src/parsing/scanner.h
index d9216f222a..a7386050d6 100644
--- a/src/parsing/scanner.h
+++ b/src/parsing/scanner.h
@@ -10,6 +10,7 @@
 #include 
 #include 

+#include "include/v8.h"
 #include "src/base/logging.h"
 #include "src/common/globals.h"
 #include "src/common/message-template.h"
diff --git a/src/runtime/runtime.h b/src/runtime/runtime.h
index f5e56ac951..0e15898f73 100644
--- a/src/runtime/runtime.h
+++ b/src/runtime/runtime.h
@@ -7,6 +7,7 @@

 #include 

+#include "include/v8.h"
 #include "src/base/platform/time.h"
 #include "src/common/globals.h"
 #include "src/objects/elements-kind.h"
diff --git a/src/utils/utils.h b/src/utils/utils.h
index 6f04ea63d3..8ba4e6bef7 100644
--- a/src/utils/utils.h
+++ b/src/utils/utils.h
@@ -12,7 +12,6 @@
 #include 
 #include 

-#include "include/v8.h"
 #include "src/base/bits.h"
 #include "src/base/compiler-specific.h"
 #include "src/base/logging.h"

Please try that and see if it works and I'll upload up to master.


On Thu, 14 Nov 2019 at 11:06, Ben Ernst  wrote:

> Dan,
>
> Yes, torque builds OK.
>
> I have attached the preprocessed output, zipped up. I hope that this tells
> you something.
>
> I tried building the following versions of V8 (in addition to 7.8 I was
> building originally), they all have essentially the same problem.
>
> 7.9.317.22
> 7.7.299.15
> 7.2.502.28
>
> Thank you in advance for any ideas.
> Ben
>
> On Thursday, 14 November 2019 20:47:56 UTC+10:30, Dan Elphick wrote:
>>
>> If instead of building everything, does torque build? e.g. ninja -C
>>  torque. It looks like it does from the log but just want to
>> check. It seems odd that it can build that one but not the other simpler
>> executable.
>>
>> Below  is the command line for building bytecode-operands.obj from your
>> log. It specifies only the single .cc which doesn't include very much at
>> all so I don't see how it would get those symbols. You could try adding the
>> /P option to cl.exe (
>> https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019
>> )
>> and see what the preprocessed output is.
>>
>> ninja -t msvc -e environment.x64
>> --
>> "C:\Program Files (x86)\Microsoft Visual
>> Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
>> /nologo /showIncludes
>> -DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C
>> -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
>> -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
>> -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
>> -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN
>> -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_RS2
>> -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
>> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
>> -DENABLE_MINOR_MC -DV8_INTL_SUPPORT -DV8_USE_SNAPSHOT
>> -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING
>> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
>> -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
>> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
>> -DV8_TARGET_ARCH_X64
>> -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DBUILDING_V8_SHARED
>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
>> -DUSING_V8_BASE_SHARED
>> -I../..  -I../..  -Igen -I../..  -Igen
>> /Gy /FS
>> /bigobj
>> /utf-8
>> /Zc:twoPhase /Zc:sizedDealloc-
>> /wd4117
>> /D__DATE__= /D__TIME__= /D__TIMESTAMP__=
>> /W4 /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355
>> /wd4503 /wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510
>> /wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459
>> /wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389
>> /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715
>> /Zi /MD
>> /wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709 /wd4714 /wd4715
>> /wd4718 /wd4723 /wd4724 /wd4800
>> /O2 /Ob2 /Oy- /Zc:inline /Gw /TP /wd4577 /GR-
>> /c ../../src/interpreter/bytecode-operands.cc
>> /Foobj/bytecode_builtins_list_generator/bytecode-operands.obj
>> /Fd"obj/bytecode_builtins_list_generator_cc.pdb"
>>
>>
>>
>> On Wed, 13 Nov 2019 at 20:38, Ben Ernst  wrote:
>>
>>> Dan,
>>>
>>> I've attached the output from a clean build with "-v" as you suggested.
>>>

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick 
If instead of building everything, does torque build? e.g. ninja -C
 torque. It looks like it does from the log but just want to
check. It seems odd that it can build that one but not the other simpler
executable.

Below  is the command line for building bytecode-operands.obj from your
log. It specifies only the single .cc which doesn't include very much at
all so I don't see how it would get those symbols. You could try adding the
/P option to cl.exe (
https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019)
and see what the preprocessed output is.

ninja -t msvc -e environment.x64
--
"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64/cl.exe"
/nologo /showIncludes
-DUSE_AURA=1 -D_HAS_EXCEPTIONS=0 -DCOMPONENT_BUILD -D__STD_C -D_CRT_RAND_S
-D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
-D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
-DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNOMINMAX
-D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_RS2
-D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
-DENABLE_MINOR_MC -DV8_INTL_SUPPORT -DV8_USE_SNAPSHOT
-DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING
-DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_EMBEDDED_BUILTINS
-DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO
-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_DEPRECATION_WARNINGS
-DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64
-DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DBUILDING_V8_SHARED
-DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
-DUSING_V8_BASE_SHARED
-I../..  -I../..  -Igen -I../..  -Igen
/Gy /FS
/bigobj
/utf-8
/Zc:twoPhase /Zc:sizedDealloc-
/wd4117
/D__DATE__= /D__TIME__= /D__TIMESTAMP__=
/W4 /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503
/wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510
/wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459
/wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389
/wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715
/Zi /MD
/wd4245 /wd4267 /wd4324 /wd4701 /wd4702 /wd4703 /wd4709 /wd4714 /wd4715
/wd4718 /wd4723 /wd4724 /wd4800
/O2 /Ob2 /Oy- /Zc:inline /Gw /TP /wd4577 /GR-
/c ../../src/interpreter/bytecode-operands.cc
/Foobj/bytecode_builtins_list_generator/bytecode-operands.obj
/Fd"obj/bytecode_builtins_list_generator_cc.pdb"



On Wed, 13 Nov 2019 at 20:38, Ben Ernst  wrote:

> Dan,
>
> I've attached the output from a clean build with "-v" as you suggested.
> Thoroughly appreciate any advice. Quite desperate at this point.
>
> Marcelo,
>
> Thank you for the suggestion. Using "is_clang=true" succeeds, but results
> in a binary that is unusable. It cannot be imported into an MSVC project
> due to unresolved symbols. It looks like certain symbols clang doesn't
> think needs to be exported, but MSVC does expect them to be exported. My
> motivation for "use_custom_libcxx" is similar.
>
> Ben
>
> On Wednesday, 13 November 2019 22:27:39 UTC+10:30, Dan Elphick wrote:
>>
>> That's very odd. bytecode_builtins_list_generator is a very small
>> executable that depends on base and generates a header file. It should not
>> be using any of the symbols in your log below and would usually be built
>> and linked before compiling the files containing those symbols.
>>
>> Could you do a clean build and give the output of running the build with
>> ninja -v (so it prints all build commands even if they succeed)? Just the
>> lines involving the obj files in your log should be enough.
>>
>> Thanks,
>> Dan
>>
>> On Wed, 13 Nov 2019 at 11:32, Ben Ernst  wrote:
>>
>>> My full gn args are as follows:
>>>
>>> is_debug = false
>>> target_cpu = "x64"
>>> treat_warnings_as_errors=false
>>> is_component_build=true
>>> v8_enable_i18n_support=false
>>> v8_use_snapshot=true
>>> use_custom_libcxx=false
>>> is_clang=false
>>>
>>> But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I
>>> get the following errors (among many others):
>>>
>>> [exec] [7/685] LINK bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec] FAILED: bytecode_builtins_list_generator.exe
>>> bytecode_builtins_list_generator.exe.pdb
>>>  [exec]
>>> C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>>> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
>>> /PDB:./bytecode_builtins_list_generator.exe.pdb
>>> @./bytecode_builtins_list_generator.exe.rsp
>>>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
>>> unresolved external symbol "class v8::internal::Isolate * __cdecl
>>> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
>>>

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Marcelo Rocha 
Hi,

I suggest removing the line "is_clang=false", to use the default value. I
had problem using this configuration in the past.

Em qua., 13 de nov. de 2019 às 08:32, Ben Ernst  escreveu:

> My full gn args are as follows:
>
> is_debug = false
> target_cpu = "x64"
> treat_warnings_as_errors=false
> is_component_build=true
> v8_enable_i18n_support=false
> v8_use_snapshot=true
> use_custom_libcxx=false
> is_clang=false
>
> But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I
> get the following errors (among many others):
>
> [exec] [7/685] LINK bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec] FAILED: bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec]
> C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
> /PDB:./bytecode_builtins_list_generator.exe.pdb
> @./bytecode_builtins_list_generator.exe.rsp
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
> referenced in function "public: class v8::Local __cdecl
> v8::Context::GetEmbedderData(int)" (?GetEmbedderData@Context@v8@
> @QEAA?AV?$Local@VValue@v8@@@2@H@Z)
>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
> symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
> "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "public: __cdecl
> v8::HandleScope::~HandleScope(void)" (??1HandleScope@v8@@QEAA@XZ)
> referenced in function "public: __cdecl
> v8::EscapableHandleScope::~EscapableHandleScope(void)"
> (??1EscapableHandleScope@v8@@QEAA@XZ)
>
>
> What could I be doing wrong? Any suggestions appreciated.
>
>
>
> On Wednesday, 6 November 2019 21:30:10 UTC+10:30, Ben Ernst wrote:
>>
>> Thanks Hans, I'm sure I tried that before, but I'll give that a shot
>> again. Ben.
>>
>> On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote:
>>>
>>> Hi,
>>>
>>> the libc provided together with v8 is incompatible with the msvc-libc.
>>> I had to provide "use_custom_libcxx=false" to be able to link it with
>>> my own program.
>>>
>>>
>>> Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:

 Of note, the sample utilities "d8" and "v8_hello_world" build fine, and
 they don't get this same linker error. I can't see anything I'm doing
 differently, however.

 On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>
> Thanks Jakob, is there by any chance a correpsonding buildbot for
> Windows and MSVC++? I get this linker error from it seems V8 7.2 onwards,
> although I'm focussing on 7.8. The "monolith" build seems to be working
> though. I wonder if it's an MSVC++ peculiarity that is tripping me up?
> Regards,
> Ben
>
> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>>
>> Yes, the component build is expected to work for every version, and
>> our buildbot thinks it does:
>> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>>
>> The component build is also the default in Debug mode, which most V8
>> developers compile/use every day.
>>
>>
>> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>>
>>> Is the idea of a "component build", where you specify
>>> "is_component_build=true" in the arguments to GN, actually supposed to 
>>> work
>>> at all in V8 (v7.8)?
>>>
>>> In particular, I am getting this unresolved external symbol:
>>>
>>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol
>>> "__declspec(dllimport) class std::unique_ptr>> std::default_delete > __cdecl
>>> v8::platform::NewDefaultPlatform(int,enum
>>> v8::platform::IdleTaskSupport,enum
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct std::default_delete>> v8::TracingController> >)" (__imp_?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) referenced

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Dan Elphick 
That's very odd. bytecode_builtins_list_generator is a very small
executable that depends on base and generates a header file. It should not
be using any of the symbols in your log below and would usually be built
and linked before compiling the files containing those symbols.

Could you do a clean build and give the output of running the build with
ninja -v (so it prints all build commands even if they succeed)? Just the
lines involving the obj files in your log should be enough.

Thanks,
Dan

On Wed, 13 Nov 2019 at 11:32, Ben Ernst  wrote:

> My full gn args are as follows:
>
> is_debug = false
> target_cpu = "x64"
> treat_warnings_as_errors=false
> is_component_build=true
> v8_enable_i18n_support=false
> v8_use_snapshot=true
> use_custom_libcxx=false
> is_clang=false
>
> But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I
> get the following errors (among many others):
>
> [exec] [7/685] LINK bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec] FAILED: bytecode_builtins_list_generator.exe
> bytecode_builtins_list_generator.exe.pdb
>  [exec]
> C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe
> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
> False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe
> /PDB:./bytecode_builtins_list_generator.exe.pdb
> @./bytecode_builtins_list_generator.exe.rsp
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
> referenced in function "public: class v8::Local __cdecl
> v8::Context::GetEmbedderData(int)" (?GetEmbedderData@Context@v8@
> @QEAA?AV?$Local@VValue@v8@@@2@H@Z)
>  [exec] bytecode-operands.obj : error LNK2001: unresolved external
> symbol "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] bytecodes.obj : error LNK2001: unresolved external symbol
> "class v8::internal::Isolate * __cdecl
> v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)"
> (?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
>  [exec] generate-bytecodes-builtins-list.obj : error LNK2019:
> unresolved external symbol "public: __cdecl
> v8::HandleScope::~HandleScope(void)" (??1HandleScope@v8@@QEAA@XZ)
> referenced in function "public: __cdecl
> v8::EscapableHandleScope::~EscapableHandleScope(void)"
> (??1EscapableHandleScope@v8@@QEAA@XZ)
>
>
> What could I be doing wrong? Any suggestions appreciated.
>
>
>
> On Wednesday, 6 November 2019 21:30:10 UTC+10:30, Ben Ernst wrote:
>>
>> Thanks Hans, I'm sure I tried that before, but I'll give that a shot
>> again. Ben.
>>
>> On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote:
>>>
>>> Hi,
>>>
>>> the libc provided together with v8 is incompatible with the msvc-libc.
>>> I had to provide "use_custom_libcxx=false" to be able to link it with
>>> my own program.
>>>
>>>
>>> Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:

 Of note, the sample utilities "d8" and "v8_hello_world" build fine, and
 they don't get this same linker error. I can't see anything I'm doing
 differently, however.

 On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>
> Thanks Jakob, is there by any chance a correpsonding buildbot for
> Windows and MSVC++? I get this linker error from it seems V8 7.2 onwards,
> although I'm focussing on 7.8. The "monolith" build seems to be working
> though. I wonder if it's an MSVC++ peculiarity that is tripping me up?
> Regards,
> Ben
>
> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>>
>> Yes, the component build is expected to work for every version, and
>> our buildbot thinks it does:
>> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>>
>> The component build is also the default in Debug mode, which most V8
>> developers compile/use every day.
>>
>>
>> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>>
>>> Is the idea of a "component build", where you specify
>>> "is_component_build=true" in the arguments to GN, actually supposed to 
>>> work
>>> at all in V8 (v7.8)?
>>>
>>> In particular, I am getting this unresolved external symbol:
>>>
>>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol
>>> "__declspec(dllimport) class std::unique_ptr>> std::default_delete > __cdecl
>>> v8::platform::NewDefaultPlatform(int,enum
>>> v8::platform::IdleTaskSupport,enum
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Ben Ernst 
My full gn args are as follows:

is_debug = false
target_cpu = "x64"
treat_warnings_as_errors=false
is_component_build=true
v8_enable_i18n_support=false
v8_use_snapshot=true
use_custom_libcxx=false
is_clang=false

But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I 
get the following errors (among many others):

[exec] [7/685] LINK bytecode_builtins_list_generator.exe 
bytecode_builtins_list_generator.exe.pdb
 [exec] FAILED: bytecode_builtins_list_generator.exe 
bytecode_builtins_list_generator.exe.pdb
 [exec] 
C:/6faf51f1/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe 
../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 
False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe 
/PDB:./bytecode_builtins_list_generator.exe.pdb 
@./bytecode_builtins_list_generator.exe.rsp
 [exec] generate-bytecodes-builtins-list.obj : error LNK2019: 
unresolved external symbol "class v8::internal::Isolate * __cdecl 
v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)" 
(?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z) 
referenced in function "public: class v8::Local __cdecl 
v8::Context::GetEmbedderData(int)" 
(?GetEmbedderData@Context@v8@@QEAA?AV?$Local@VValue@v8@@@2@H@Z)
 [exec] bytecode-operands.obj : error LNK2001: unresolved external 
symbol "class v8::internal::Isolate * __cdecl 
v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)" 
(?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
 [exec] bytecodes.obj : error LNK2001: unresolved external symbol 
"class v8::internal::Isolate * __cdecl 
v8::internal::IsolateFromNeverReadOnlySpaceObject(unsigned __int64)" 
(?IsolateFromNeverReadOnlySpaceObject@internal@v8@@YAPEAVIsolate@12@_K@Z)
 [exec] generate-bytecodes-builtins-list.obj : error LNK2019: 
unresolved external symbol "public: __cdecl 
v8::HandleScope::~HandleScope(void)" (??1HandleScope@v8@@QEAA@XZ) 
referenced in function "public: __cdecl 
v8::EscapableHandleScope::~EscapableHandleScope(void)" 
(??1EscapableHandleScope@v8@@QEAA@XZ)


What could I be doing wrong? Any suggestions appreciated.



On Wednesday, 6 November 2019 21:30:10 UTC+10:30, Ben Ernst wrote:
>
> Thanks Hans, I'm sure I tried that before, but I'll give that a shot 
> again. Ben.
>
> On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote:
>>
>> Hi,
>>
>> the libc provided together with v8 is incompatible with the msvc-libc.
>> I had to provide "use_custom_libcxx=false" to be able to link it with my 
>> own program.
>>
>>
>> Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:
>>>
>>> Of note, the sample utilities "d8" and "v8_hello_world" build fine, and 
>>> they don't get this same linker error. I can't see anything I'm doing 
>>> differently, however.
>>>
>>> On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:

 Thanks Jakob, is there by any chance a correpsonding buildbot for 
 Windows and MSVC++? I get this linker error from it seems V8 7.2 onwards, 
 although I'm focussing on 7.8. The "monolith" build seems to be working 
 though. I wonder if it's an MSVC++ peculiarity that is tripping me up?
 Regards,
 Ben

 On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>
> Yes, the component build is expected to work for every version, and 
> our buildbot thinks it does: 
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>
> The component build is also the default in Debug mode, which most V8 
> developers compile/use every day.
>
>
> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>
>> Is the idea of a "component build", where you specify 
>> "is_component_build=true" in the arguments to GN, actually supposed to 
>> work 
>> at all in V8 (v7.8)?
>>
>> In particular, I am getting this unresolved external symbol:
>>
>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol 
>> "__declspec(dllimport) class std::unique_ptr> std::default_delete > __cdecl 
>> v8::platform::NewDefaultPlatform(int,enum 
>> v8::platform::IdleTaskSupport,enum 
>> v8::platform::InProcessStackDumping,class std::unique_ptr> v8::TracingController,struct std::default_delete> v8::TracingController> >)" 
>> (__imp_?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)
>>  
>> referenced in function "public: __cdecl 
>> ezv8::Platform::Impl::Impl(void)" 
>> (??0Impl@Platform@ezv8@@QEAA@XZ)
>>
>> The function "NewDefaultPlatform" seems to be exported from 
>> v8_libplatform.
>>
>> V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
>> int thread_pool_size = 0,

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-06 Thread Ben Ernst 
Thanks Hans, I'm sure I tried that before, but I'll give that a shot again. 
Ben.

On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote:
>
> Hi,
>
> the libc provided together with v8 is incompatible with the msvc-libc.
> I had to provide "use_custom_libcxx=false" to be able to link it with my 
> own program.
>
>
> Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:
>>
>> Of note, the sample utilities "d8" and "v8_hello_world" build fine, and 
>> they don't get this same linker error. I can't see anything I'm doing 
>> differently, however.
>>
>> On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>>>
>>> Thanks Jakob, is there by any chance a correpsonding buildbot for 
>>> Windows and MSVC++? I get this linker error from it seems V8 7.2 onwards, 
>>> although I'm focussing on 7.8. The "monolith" build seems to be working 
>>> though. I wonder if it's an MSVC++ peculiarity that is tripping me up?
>>> Regards,
>>> Ben
>>>
>>> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:

 Yes, the component build is expected to work for every version, and our 
 buildbot thinks it does: 
 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared

 The component build is also the default in Debug mode, which most V8 
 developers compile/use every day.


 On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:

> Is the idea of a "component build", where you specify 
> "is_component_build=true" in the arguments to GN, actually supposed to 
> work 
> at all in V8 (v7.8)?
>
> In particular, I am getting this unresolved external symbol:
>
> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol 
> "__declspec(dllimport) class std::unique_ptr std::default_delete > __cdecl 
> v8::platform::NewDefaultPlatform(int,enum 
> v8::platform::IdleTaskSupport,enum 
> v8::platform::InProcessStackDumping,class std::unique_ptr v8::TracingController,struct std::default_delete v8::TracingController> >)" 
> (__imp_?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)
>  
> referenced in function "public: __cdecl ezv8::Platform::Impl::Impl(void)" 
> (??0Impl@Platform@ezv8@@QEAA@XZ)
>
> The function "NewDefaultPlatform" seems to be exported from 
> v8_libplatform.
>
> V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
> int thread_pool_size = 0,
> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
> InProcessStackDumping in_process_stack_dumping =
> InProcessStackDumping::kDisabled,
> std::unique_ptr tracing_controller = {});
>
> But the destructor of the base class, v8::Platform is not exported.
>
> /**
>  * V8 Platform abstraction layer.
>  *
>  * The embedder has to provide an implementation of this interface 
> before
>  * initializing the rest of V8.
>  */
> class Platform {
>  public:
>   virtual ~Platform() = default;
>
>
> I think that's the cause of the error above, although I may have 
> misinterpreted the error message.
>
> Am I barking up the wrong tree by trying to use the component build at 
> all?
>
> Thanks in advance for any advice.
>
>
>
>

-- 
-- 
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/6ac7f191-a70b-47ed-8410-c48835e78fdf%40googlegroups.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-03 Thread Hans Maier 
Hi,

the libc provided together with v8 is incompatible with the msvc-libc.
I had to provide "use_custom_libcxx=false" to be able to link it with my 
own program.


Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst:
>
> Of note, the sample utilities "d8" and "v8_hello_world" build fine, and 
> they don't get this same linker error. I can't see anything I'm doing 
> differently, however.
>
> On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>>
>> Thanks Jakob, is there by any chance a correpsonding buildbot for Windows 
>> and MSVC++? I get this linker error from it seems V8 7.2 onwards, although 
>> I'm focussing on 7.8. The "monolith" build seems to be working though. I 
>> wonder if it's an MSVC++ peculiarity that is tripping me up?
>> Regards,
>> Ben
>>
>> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>>>
>>> Yes, the component build is expected to work for every version, and our 
>>> buildbot thinks it does: 
>>> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>>>
>>> The component build is also the default in Debug mode, which most V8 
>>> developers compile/use every day.
>>>
>>>
>>> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>>>
 Is the idea of a "component build", where you specify 
 "is_component_build=true" in the arguments to GN, actually supposed to 
 work 
 at all in V8 (v7.8)?

 In particular, I am getting this unresolved external symbol:

 1>ezv8_platform.obj : error LNK2019: unresolved external symbol 
 "__declspec(dllimport) class std::unique_ptr>>> std::default_delete > __cdecl 
 v8::platform::NewDefaultPlatform(int,enum 
 v8::platform::IdleTaskSupport,enum 
 v8::platform::InProcessStackDumping,class std::unique_ptr>>> v8::TracingController,struct std::default_delete>>> v8::TracingController> >)" 
 (__imp_?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)
  
 referenced in function "public: __cdecl ezv8::Platform::Impl::Impl(void)" 
 (??0Impl@Platform@ezv8@@QEAA@XZ)

 The function "NewDefaultPlatform" seems to be exported from 
 v8_libplatform.

 V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
 int thread_pool_size = 0,
 IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
 InProcessStackDumping in_process_stack_dumping =
 InProcessStackDumping::kDisabled,
 std::unique_ptr tracing_controller = {});

 But the destructor of the base class, v8::Platform is not exported.

 /**
  * V8 Platform abstraction layer.
  *
  * The embedder has to provide an implementation of this interface 
 before
  * initializing the rest of V8.
  */
 class Platform {
  public:
   virtual ~Platform() = default;


 I think that's the cause of the error above, although I may have 
 misinterpreted the error message.

 Am I barking up the wrong tree by trying to use the component build at 
 all?

 Thanks in advance for any advice.





-- 
-- 
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/90d39cd7-0fc1-4730-9da9-9e0cc37bca3c%40googlegroups.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-03 Thread Ben Ernst 
Of note, the sample utilities "d8" and "v8_hello_world" build fine, and 
they don't get this same linker error. I can't see anything I'm doing 
differently, however.

On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote:
>
> Thanks Jakob, is there by any chance a correpsonding buildbot for Windows 
> and MSVC++? I get this linker error from it seems V8 7.2 onwards, although 
> I'm focussing on 7.8. The "monolith" build seems to be working though. I 
> wonder if it's an MSVC++ peculiarity that is tripping me up?
> Regards,
> Ben
>
> On Saturday, 2 November 2019 02:17:38 UTC+10:30, Jakob Kummerow wrote:
>>
>> Yes, the component build is expected to work for every version, and our 
>> buildbot thinks it does: 
>> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared
>>
>> The component build is also the default in Debug mode, which most V8 
>> developers compile/use every day.
>>
>>
>> On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:
>>
>>> Is the idea of a "component build", where you specify 
>>> "is_component_build=true" in the arguments to GN, actually supposed to work 
>>> at all in V8 (v7.8)?
>>>
>>> In particular, I am getting this unresolved external symbol:
>>>
>>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol 
>>> "__declspec(dllimport) class std::unique_ptr>> std::default_delete > __cdecl 
>>> v8::platform::NewDefaultPlatform(int,enum 
>>> v8::platform::IdleTaskSupport,enum 
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct std::default_delete>> v8::TracingController> >)" 
>>> (__imp_?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)
>>>  
>>> referenced in function "public: __cdecl ezv8::Platform::Impl::Impl(void)" 
>>> (??0Impl@Platform@ezv8@@QEAA@XZ)
>>>
>>> The function "NewDefaultPlatform" seems to be exported from 
>>> v8_libplatform.
>>>
>>> V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
>>> int thread_pool_size = 0,
>>> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
>>> InProcessStackDumping in_process_stack_dumping =
>>> InProcessStackDumping::kDisabled,
>>> std::unique_ptr tracing_controller = {});
>>>
>>> But the destructor of the base class, v8::Platform is not exported.
>>>
>>> /**
>>>  * V8 Platform abstraction layer.
>>>  *
>>>  * The embedder has to provide an implementation of this interface before
>>>  * initializing the rest of V8.
>>>  */
>>> class Platform {
>>>  public:
>>>   virtual ~Platform() = default;
>>>
>>>
>>> I think that's the cause of the error above, although I may have 
>>> misinterpreted the error message.
>>>
>>> Am I barking up the wrong tree by trying to use the component build at 
>>> all?
>>>
>>> Thanks in advance for any advice.
>>>
>>>
>>>
>>>

-- 
-- 
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/e78c6991-e961-41ba-bfc8-db9882f2ddc6%40googlegroups.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-01 Thread Jakob Kummerow 
Yes, the component build is expected to work for every version, and our
buildbot thinks it does:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared

The component build is also the default in Debug mode, which most V8
developers compile/use every day.


On Fri, Nov 1, 2019 at 1:00 AM Ben Ernst  wrote:

> Is the idea of a "component build", where you specify
> "is_component_build=true" in the arguments to GN, actually supposed to work
> at all in V8 (v7.8)?
>
> In particular, I am getting this unresolved external symbol:
>
> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) class std::unique_ptr std::default_delete > __cdecl
> v8::platform::NewDefaultPlatform(int,enum
> v8::platform::IdleTaskSupport,enum
> v8::platform::InProcessStackDumping,class std::unique_ptr v8::TracingController,struct std::default_delete v8::TracingController> >)" (__imp_?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) referenced in function "public: __cdecl
> ezv8::Platform::Impl::Impl(void)" (??0Impl@Platform@ezv8@@QEAA@XZ)
>
> The function "NewDefaultPlatform" seems to be exported from
> v8_libplatform.
>
> V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
> int thread_pool_size = 0,
> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
> InProcessStackDumping in_process_stack_dumping =
> InProcessStackDumping::kDisabled,
> std::unique_ptr tracing_controller = {});
>
> But the destructor of the base class, v8::Platform is not exported.
>
> /**
>  * V8 Platform abstraction layer.
>  *
>  * The embedder has to provide an implementation of this interface before
>  * initializing the rest of V8.
>  */
> class Platform {
>  public:
>   virtual ~Platform() = default;
>
>
> I think that's the cause of the error above, although I may have
> misinterpreted the error message.
>
> Am I barking up the wrong tree by trying to use the component build at all?
>
> Thanks in advance for any advice.
>
>
>
>

-- 
-- 
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/CAKSzg3QznZ_GuHkRG8mHpmUsS%2BPWV8JNrBBW5kEEUydNoh7Lgg%40mail.gmail.com.

[v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-10-31 Thread Ben Ernst 
Is the idea of a "component build", where you specify 
"is_component_build=true" in the arguments to GN, actually supposed to work 
at all in V8 (v7.8)?

In particular, I am getting this unresolved external symbol:

1>ezv8_platform.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) class std::unique_ptr > __cdecl 
v8::platform::NewDefaultPlatform(int,enum 
v8::platform::IdleTaskSupport,enum 
v8::platform::InProcessStackDumping,class std::unique_ptr >)" 
(__imp_?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)
 
referenced in function "public: __cdecl ezv8::Platform::Impl::Impl(void)" 
(??0Impl@Platform@ezv8@@QEAA@XZ)

The function "NewDefaultPlatform" seems to be exported from v8_libplatform.

V8_PLATFORM_EXPORT std::unique_ptr NewDefaultPlatform(
int thread_pool_size = 0,
IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
InProcessStackDumping in_process_stack_dumping =
InProcessStackDumping::kDisabled,
std::unique_ptr tracing_controller = {});

But the destructor of the base class, v8::Platform is not exported.

/**
 * V8 Platform abstraction layer.
 *
 * The embedder has to provide an implementation of this interface before
 * initializing the rest of V8.
 */
class Platform {
 public:
  virtual ~Platform() = default;


I think that's the cause of the error above, although I may have 
misinterpreted the error message.

Am I barking up the wrong tree by trying to use the component build at all?

Thanks in advance for any advice.



-- 
-- 
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/34747261-186a-43b3-8383-9d85857b2e66%40googlegroups.com.