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