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