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-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/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-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_77vm2o1Lp7o5dm1ONYP0M9KiO855RQEzuKKrUgSf9ih48g%40mail.gmail.com.
