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 <https://chromium-review.googlesource.com/c/v8/v8/+/1914215> 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 <boi...@gmail.com> 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 >> <https://crbug.com/v8/8912>, 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 <delp...@chromium.org> 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 <boi...@gmail.com> 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 <algorithm> >>>>>> #include <memory> >>>>>> >>>>>> +#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 <memory> >>>>>> >>>>>> +#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 <string> >>>>>> #include <type_traits> >>>>>> >>>>>> -#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 <boi...@gmail.com> 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 >>>>>>>> <build-dir> 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 >>>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Freference%2Fp-preprocess-to-a-file%3Fview%3Dvs-2019&sa=D&sntz=1&usg=AFQjCNG-ELxt9CxA61sjMVK-8z8nrL4Efg>) >>>>>>>> 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 <boi...@gmail.com> 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 <boi...@gmail.com> 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<class v8::Value> __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 <boi...@gmail.com> >>>>>>>>>>>>>>>> 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<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> >)" (__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<v8::Platform> >>>>>>>>>>>>>>>>> NewDefaultPlatform( >>>>>>>>>>>>>>>>> int thread_pool_size = 0, >>>>>>>>>>>>>>>>> IdleTaskSupport idle_task_support = >>>>>>>>>>>>>>>>> IdleTaskSupport::kDisabled, >>>>>>>>>>>>>>>>> InProcessStackDumping in_process_stack_dumping = >>>>>>>>>>>>>>>>> InProcessStackDumping::kDisabled, >>>>>>>>>>>>>>>>> std::unique_ptr<v8::TracingController> >>>>>>>>>>>>>>>>> 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-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/6d7d3682-8f5c-431a-85fe-b929d9834522%40googlegroups.com >>>>>>>>>>> <https://groups.google.com/d/msgid/v8-users/6d7d3682-8f5c-431a-85fe-b929d9834522%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/d4243240-9bdb-4b9f-971f-b191ab2aeab5%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/v8-users/d4243240-9bdb-4b9f-971f-b191ab2aeab5%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/7a894267-c1c1-4b79-ac92-e1840b002d70%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/v8-users/7a894267-c1c1-4b79-ac92-e1840b002d70%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/a138e0cb-631b-41b5-b9f3-4147db3366b2%40googlegroups.com >>>> <https://groups.google.com/d/msgid/v8-users/a138e0cb-631b-41b5-b9f3-4147db3366b2%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/CALH_77vm2o1Lp7o5dm1ONYP0M9KiO855RQEzuKKrUgSf9ih48g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/v8-users/CALH_77vm2o1Lp7o5dm1ONYP0M9KiO855RQEzuKKrUgSf9ih48g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> Clemens Backes >> >> (né Hammacher) >> >> Software Engineer >> >> clem...@google.com >> >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> >> >> >> -- >> >> Clemens Backes >> >> (né Hammacher) >> >> Software Engineer >> >> clem...@google.com >> >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> >> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> > -- > -- > 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/a0fa2b1c-0635-4468-94eb-45579f36e0af%40googlegroups.com > <https://groups.google.com/d/msgid/v8-users/a0fa2b1c-0635-4468-94eb-45579f36e0af%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/CALH_77t%2Byn4u-LttrGKystooHD05GZ5vATU0or86kyQ9uFx%2BrQ%40mail.gmail.com.
