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 <javascript:>>
> 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 <javascript:>
>> 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 <javascript:>.
>> 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/c03232a5-9d93-422f-ab9a-676160a377dc%40googlegroups.com.
