Re: [v8-users] Request for Information: MSVC Support Status for V8 in Version 13

[Ben Ernst]

Is it necessary to use clang for the whole program?



On Tue, 15 Oct 2024 at 15:57, J Decker  wrote:

>
>
> On Sat, Oct 12, 2024 at 2:34 AM Pradish  wrote:
>
>> Dear V8 Project Contributors,
>>
>> I hope this message finds you well. First, I'd like to express my
>> appreciation for your work on the V8 project. The engine has been a crucial
>> component in many projects, including ours.
>>
>> I'm reaching out to the community to gather some information about the
>> current status of Microsoft Visual C++ (MSVC) support in V8, particularly
>> for embedding V8 as a shared DLL or as static libraray. We've been using V8
>> in this configuration(shared dll)  and have some questions about its future
>> support.
>>
>> We've noticed that V8 version 13 has been released, but we couldn't find
>> specific information *in the commit tags or on V8 Blog* *regarding MSVC
>> support depreciation,  *We've also seen some discussions in the
>> community suggesting *potential changes to MSVC support*.
>>
>> If possible, we'd greatly appreciate any insights on the following:
>>
>>1. What is the current status of MSVC support for V8
>>2. Are there any plans to change MSVC support in future versions? If
>>so, is there a general timeline available?
>>3. Are there any specific considerations in Version 13 that affect
>>MSVC compatibility, especially for shared DLL usage?
>>4.  If changes to MSVC support are planned, are there recommended
>>alternatives for projects using V8 as a shared DLL on Windows platforms?
>>5. Could you point us to any documentation or resources that might
>>help us understand the project's direction regarding MSVC support?
>>
>> Enable clang for use instead... this isn't so bad... and then visual
> studio/msbuild still work the same, just MSVC becomes Clang-CL; and
> Clang-CL mostly understands cl.exe flags rather than gcc sort of flags
>
> https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170
>
>
>>
>> We understand that as an open source project, plans can change, so any
>> information you can provide would be incredibly helpful for our planning
>> and potential contributions to the project.
>>
>> Thank you for your time and for your continued work on V8.
>>
>> Best regards,
>> Pradish
>>
>> --
>> --
>> 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/dd80071e-a7f8-4e10-8e5a-912daa709538n%40googlegroups.com
>> 
>> .
>>
> --
> --
> 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/CAA2GJqWKTfo39i%2BYkhj3N_tb3MchNPR8XYyXxJhv-LL7z1HZUw%40mail.gmail.com
> 
> .
>

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

Re: [v8-users] Request for Information: MSVC Support Status for V8 in Version 13

[Ben Ernst]

Has anyone collected any notes on switching to clang-cl? I need to do this
as well.
Ben



On Sat, 12 Oct 2024 at 17:09, Ben Noordhuis  wrote:

> On Sat, Oct 12, 2024 at 11:34 AM Pradish  wrote:
> >
> > Dear V8 Project Contributors,
> >
> > I hope this message finds you well. First, I'd like to express my
> appreciation for your work on the V8 project. The engine has been a crucial
> component in many projects, including ours.
> >
> > I'm reaching out to the community to gather some information about the
> current status of Microsoft Visual C++ (MSVC) support in V8, particularly
> for embedding V8 as a shared DLL or as static libraray. We've been using V8
> in this configuration(shared dll)  and have some questions about its future
> support.
> >
> > We've noticed that V8 version 13 has been released, but we couldn't find
> specific information in the commit tags or on V8 Blog regarding MSVC
> support depreciation,  We've also seen some discussions in the community
> suggesting potential changes to MSVC support.
> >
> > If possible, we'd greatly appreciate any insights on the following:
> >
> > What is the current status of MSVC support for V8
> > Are there any plans to change MSVC support in future versions? If so, is
> there a general timeline available?
> > Are there any specific considerations in Version 13 that affect MSVC
> compatibility, especially for shared DLL usage?
> >  If changes to MSVC support are planned, are there recommended
> alternatives for projects using V8 as a shared DLL on Windows platforms?
> > Could you point us to any documentation or resources that might help us
> understand the project's direction regarding MSVC support?
> >
> >
> > We understand that as an open source project, plans can change, so any
> information you can provide would be incredibly helpful for our planning
> and potential contributions to the project.
> >
> > Thank you for your time and for your continued work on V8.
> >
> > Best regards,
> > Pradish
>
> Not a V8 maintainer, just a downstream user, but I believe the
> direction going forward can be summarized as: switch to clang-cl.
>
> As to timelines: I don't believe upstream tests msvc any longer so you
> might as well start now.
>
> --
> --
> 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/CAHQurc_sq4x4MkaSqvh5xszZ3dgJwR01UdRKhS_uN6AHfUYO-w%40mail.gmail.com
> .
>

-- 
-- 
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/CABexdQ7eADXUNfZMvi7UFNz1kXx%3Dzvp3WAH08uCbDHeD_MkaOQ%40mail.gmail.com.

Re: [v8-users] Re: Using v8's clang-cl and libc++ on Windows

[Ben Ernst]

Following your experience. I understand MSVC support will soon be
deprecated altogether, many of us will soon need to deal with some of these
more intricate integration scenarios.
---
Sent from my Nokia 3310

On Sun, 8 Sept 2024, 20:22 Nikolas Kovacs,  wrote:

>
> The solution was to add the `/Zc:dllexportsInlines-` flag
> On Friday, August 30, 2024 at 1:34:52 PM UTC-4 Nikolas Kovacs wrote:
>
>> Hi,
>> I am embedding v8 into my C++ application and I am trying to use a
>> recent, stable version. I built 12.8 (
>> e6286d70c55da94a8e12658918989b9b9dc325c8).
>>
>> I was unable to build with `use_custom_libcxx` set to false and I read
>> online that MSVC support is mostly a nice-to-have. To use this, though, I
>> believe I have to use the clang-cl and libc++ from the v8 build process to
>> build my application that is embedding it.
>>
>> So, I've been trying for a few weeks now to migrate. Things seem to be
>> working mostly fine, but I am running into some build issues with my
>> applications that I cannot resolve.
>>
>> Below I am going to share some reproducible snippets of code and their
>> errors. Hopefully someone will be able to put me in the right direction
>> because I am very stuck.
>>
>> I can't figure out how to put in code blocks, so please forgive the
>> formatting.
>>
>> # test.cpp
>> --
>>
>> #include  #include  int main() { throw std::
>> runtime_error("Hello, World!"); // breaks std::make_shared(2); //
>> breaks std::make_unique(2); // this is fine }
>>
>> ```
>> clang-cl.exe -v test.cpp -fuse-ld=lld /clang:-fexceptions /EHsc
>> -I"W:\third_party\libcxx\include" -I"W:\third_party\libcxx\include.19"
>> -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG
>> "W:\third_party\libcxx\Debug\lib\libc++.dll.lib"
>> ```
>> In the command above, the include directories are
>> `//third_party/libc++/src/include` and
>> `//third_party/llvm-build/Release+Asserts/lib/clang/19/lib/include` from
>> the v8 project respectively.
>>
>> The files `__assertion_handler` and `__config_site` were both copied into
>> the first include dir from `//build_tools/third_party/libc++`
>>
>> The errors:
>>
>> ```
>>  "W:\\VSSource\\repos\\ViciOnlineSDL2\\third_party\\clang\\lld-link"
>> -out:test.exe "-libpath:C:\\Program Files\\Microsoft Visual
>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\lib\\x64"
>> "-libpath:C:\\Program Files\\Microsoft Visual
>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\atlmfc\\lib\\x64"
>> "-libpath:C:\\Program Files (x86)\\Windows
>> Kits\\10\\Lib\\10.0.26100.0\\ucrt\\x64" "-libpath:C:\\Program Files
>> (x86)\\Windows Kits\\10\\Lib\\10.0.26100.0\\um\\x64" -nologo
>> "C:\\Users\\kovac\\AppData\\Local\\Temp\\test-7eb16d.obj"
>> "W:\\VSSource\\repos\\ViciOnlineSDL2\\third_party\\libcxx\\Debug\\lib\\libc++.dll.lib"
>> lld-link: error: undefined symbol: __declspec(dllimport) public: __cdecl
>> std::runtime_error::runtime_error(char const *)
>> >>> referenced by C:\Users\kovac\AppData\Local\Temp\test-7eb16d.obj:(main)
>>
>> lld-link: error: undefined symbol: public: __cdecl
>> std::runtime_error::runtime_error(class std::runtime_error const &)
>> >>> referenced by
>> C:\Users\kovac\AppData\Local\Temp\test-7eb16d.obj:(_CT??_R0?AVruntime_error@std
>> @@@8??0runtime_error@std@@QEAA@AEBV01@@Z24)
>>
>> lld-link: error: undefined symbol: public: virtual __cdecl
>> std::runtime_error::~runtime_error(void)
>> >>> referenced by
>> C:\Users\kovac\AppData\Local\Temp\test-7eb16d.obj:(_TI2?AVruntime_error@std
>> @@)
>> clang-cl: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> ```
>>
> --
> --
> 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/fc1ace54-1f70-406f-b030-4779361a27efn%40googlegroups.com
> 
> .
>

-- 
-- 
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/CABexdQ4giNU9SFDwW6OcTWorUisEKU0sHM9zNqxewz%3D5014gCQ%40mail.gmail.com.

[v8-users] Re: [v8-dev] MSVC will be unsupported after V8 version 13.0

[Ben Ernst]

Ouch! We do use V8 on a live project compiled with MSVC. Thought it was
worth throwing a comment out there, although I'm sure this isn't a decision
that was taken lightly.
Cheers,
Ben



On Mon, 17 Jun 2024 at 11:58, Hannes Payer  wrote:

> Hi all,
>
> V8 will follow Chromium's lead
> 
> and will discontinue support for MSVC. To give projects time to adjust, we
> will stop support after V8 version 13.0 in September 2024. After that, we
> will remove the infrastructure bots and MSVC compatibility hacks in the
> code base.
>
> Cheers,
> Hannes
>
> --
> --
> v8-dev mailing list
> v8-...@googlegroups.com
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-dev/CANaZRYwBjN3wR7MJEdk-fmkNPHWzJFd1RU1iC3SBA32MnD-uoA%40mail.gmail.com
> 
> .
>

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

Re: [v8-users] Re: is_component_build=true, use_custom_libcxx=false on Windows

[Ben Ernst]

Chris
I myself gave up on DLL version many years ago after many further years of
significant pain. The DLL configuration is consistently broken. The team is
very responsive, and problems are fixed quickly, but something else quickly
breaks soon after. I migrated to the "monolith" build, and I isolate calls
to V8 to a single one of my own DLLs. This has been a sustainable approach
for me.
Ben



On Wed, 24 Jan 2024 at 10:07, 'Andreas Beil' via v8-users <
v8-users@googlegroups.com> wrote:

> Hi Chris,
> i observe the same problem now for a while and did not manage to solve it.
> But what i observed: The 'monolith' configuration (
> *is_component_build=false*) works.
>
> Chris Hillery schrieb am Freitag, 19. Januar 2024 um 12:50:06 UTC+1:
>
>> I should mention that I've tried building v8 12.1.285.26; 12.2.247; as
>> well as whatever "fetch v8" brings me, all with the same error. However in
>> the past, I've built v8 11.6.189.8 with the same gn configuration options
>> successfully.
>>
>> Ceej
>> aka Chris Hillery
>>
>> On Friday, January 19, 2024 at 3:46:00 AM UTC-8 Chris Hillery wrote:
>>
>>> I've been trying everything I can think of to build a DLL version of v8
>>> which does not depend on the v8-supplied libc++ . As I understand it, this
>>> is the necessary configuration if I want to link v8 into a larger
>>> application that is built with other C++ libraries which use a different
>>> C++ standard library - in my case, an application built using MSVC.
>>>
>>> It seems that I need is_component_build=true to generate .dlls, and
>>> use_custom_libcxx=false to avoid building/linking against v8's libc++.
>>> However every time I've tried this, seemingly regardless of what other
>>> settings I enable or disable or whatever else I try (many many things at
>>> this point), it fails linking abseil:
>>>
>>> [734/2344] LINK(DLL) third_party_abseil-cpp_absl.dll
>>> third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
>>> FAILED: third_party_abseil-cpp_absl.dll
>>> third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
>>> ..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe
>>> "/OUT:./third_party_abseil-cpp_absl.dll" /nologo
>>> -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\18\lib\windows
>>> "-libpath:../../../../../../../Program Files/Microsoft Visual
>>> Studio/2022/Professional/VC/Tools/MSVC/14.36.32532/ATLMFC/lib/x64"
>>> "-libpath:../../../../../../../Program Files/Microsoft Visual
>>> Studio/2022/Professional/VC/Tools/MSVC/14.36.32532/lib/x64"
>>> "-libpath:../../../../../../../Program Files (x86)/Windows
>>> Kits/NETFXSDK/4.8/lib/um/x64" "-libpath:../../../../../../../Program Files
>>> (x86)/Windows Kits/10/lib/10.0.22621.0/ucrt/x64"
>>> "-libpath:../../../../../../../Program Files (x86)/Windows
>>> Kits/10/lib/10.0.22621.0/um/x64" /MACHINE:X64
>>>  "/IMPLIB:./third_party_abseil-cpp_absl.dll.lib" /DLL
>>> "/PDB:./third_party_abseil-cpp_absl.dll.pdb"
>>> "@./third_party_abseil-cpp_absl.dll.rsp"
>>> lld-link: error: : undefined symbol: public: __cdecl
>>> absl::Condition::Condition const>(bool
>>> (__cdecl *)(struct std::__Cr::atomic const *), struct
>>> std::__Cr::atomic const *)
>>> lld-link: error: : undefined symbol: public: __cdecl
>>> absl::container_internal::internal_compressed_tuple::Storage>> absl::cord_internal::CordRep **, 1, 0>::Storage>> absl::cord_internal::CordRep **, 1, 0>(struct
>>> std::__Cr::in_place_t, std::nullptr_t &&)
>>> lld-link: error: : undefined symbol: public: __cdecl
>>> absl::container_internal::internal_compressed_tuple::Storage>> absl::LogSink **, 1, 0>::Storage>> 0>(struct std::__Cr::in_place_t, std::nullptr_t &&)
>>> lld-link: error: : undefined symbol: public: __cdecl
>>> absl::container_internal::internal_compressed_tuple::Storage>> absl::status_internal::Payload *, 1, 0>::Storage>> absl::status_internal::Payload *, 1, 0>(struct
>>> std::__Cr::in_place_t, std::nullptr_t &&)
>>> lld-link: error: : undefined symbol: public: __cdecl
>>> std::__Cr::__compressed_pair>> absl::time_internal::cctz::time_zone::Impl const ***, class
>>> std::__Cr::allocator>> **> &>::__compressed_pair>> const ***, class std::__Cr::allocator>> absl::time_internal::cctz::time_zone::Impl const **> &>>> class std::__Cr::allocator>> const **> &>(std::nullptr_t &&, class std::__Cr::allocator>> absl::time_internal::cctz::time_zone::Impl const **> &)
>>>
>>> ...and quite a lot of similar errors.
>>>
>>> I have MSVC 2022 Professional installed, with Windows 11 SDK
>>> (10.0.22621.0) installed along with the Debugging Tools, as well as the ATL
>>> and MFC components.
>>>
>>> Can anyone help me get past this issue, or even just explain what the
>>> enormous error message means?
>>>
>>> Thanks,
>>> Ceej
>>> aka Chris Hillery
>>>
>> --
> --
> 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

Re: [v8-users] Unable to setup V8 build locally (//build/dotfile_settings.gni)

[Ben Ernst]

What OS are you on, and what version of v8 are you trying to build?
Have you tried just blowing away your working directory and starting again
from scratch?
Ben



On Tue, 26 Sept 2023 at 17:27, Alice Kile  wrote:

> Hello,
>
> I'm new to V8 and just trying to setup the project locally so I can=20
> officially start trying to understand / read through some of the code!=20
> Unfortunately I am currently stuck at a problem, I am following the=20
> instructions from page below:
>
> https://v8.dev/docs/build#building-v8
>
> The command that is failing for me is step 3: tools/dev/gm.py x64.release
>
> Here's the error output I am getting from running that command:
>
> $ v8 git:(8a2d9bdb0c7) gm x64.release
> # gn gen out/x64.release
> ERROR at //.gn:5:1: Unable to load=20
> "/~/chromium-project/src/v8/build/dotfile_settings.gni".
> import("//build/dotfile_settings.gni")
>
> Just googling around, I was able to figure out that this is likely=20
> because gclient did not clone the v8/build folder all together, and it=20
> does look like it but after having run gclient sync or gclient sync=20
> --force, I don't see any changes so I am clueless right now as to what=20
> the next course of action should be.
>
> Any help would be highly appreciated!
>
> Alice
>
> --
> --
> 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/bd2cc9c5-3527-4b3e-8ebd-0a6b6cde8273n%40googlegroups.com
> 
> .
>

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

[v8-users] Re: [8.7] Compile errors with Visual Studio 2019

[Ben Ernst]

Unfortunately the DLL build under MSVC++ breaks constantly and requires 
smarter people than me to fix it. If you can rearchitect your app to permit 
static linking to V8, you'll have a much better experience.
Ben.

On Wednesday, 27 January 2021 at 19:17:20 UTC+10:30 quinte...@gmail.com 
wrote:

> Hey there,
>
> I am trying to build V8 version 8.7 on Windows using Visual Studio 
> Professional 2019, but I'm getting compile errors due to what appears to be 
> missing move semantics for an std::unique_ptr:
>
> 1>  ninja -t msvc -e environment.x64 -- "C:\Program Files (x86)\Microsoft 
> Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\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 
> -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNOMINMAX 
> -D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_VB -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 
> -DENABLE_HANDLE_ZAPPING -DV8_USE_EXTERNAL_STARTUP_DATA 
> -DV8_ATOMIC_OBJECT_FIELD_WRITES -DV8_ATOMIC_MARKING_STATE 
> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_WIN64_UNWINDING_INFO 
> -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_SNAPSHOT_COMPRESSION 
> -DV8_GN_HEADER -DV8_GN_HEADER -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS 
> -DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS 
> -DBUILDING_V8_SHARED -DV8_GN_HEADER -DV8_GN_HEADER -DUSING_V8_BASE_SHARED 
> -DUSING_V8_PLATFORM_SHARED -DV8_GN_HEADER -DV8_GN_HEADER 
> -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 
> -DU_ENABLE_TRACING=1 -DU_ENABLE_RESOURCE_TRACING=0 
> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=wchar_t -I../.. -Igen 
> -I../.. -I../../include -Igen -Igen/include -Igen/include -I../../include 
> -I../../include -Igen/include -I../../third_party/icu/source/common 
> -I../../third_party/icu/source/i18n -I../../include 
> -I../../third_party/zlib /Gy /FS /bigobj /utf-8 /Zc:sizedDealloc- /wd4117 
> /D__DATE__= /D__TIME__= /D__TIMESTAMP__= /W4 /WX /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 /wd5205 /wd4506 /O2 /Ob2 /Oy- /Zc:inline 
> /Gw /TP /wd4577 /GR- /c ../../src/api/api.cc 
> /Foobj/v8_base_without_compiler/api.obj 
> /Fd"obj/v8_base_without_compiler_cc.pdb"
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\xutility(4142): 
> error C2280: 
> 'std::unique_ptr>
>  
> &std::unique_ptr>::operator
>  
> =(const 
> std::unique_ptr>
>  
> &)': attempting to reference a deleted function
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\memory(2552): 
> note: see declaration of 
> 'std::unique_ptr>::operator
>  
> ='
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\memory(2552): 
> note: 
> 'std::unique_ptr>
>  
> &std::unique_ptr>::operator
>  
> =(const 
> std::unique_ptr>
>  
> &)': function was explicitly deleted
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\vector(1127): 
> note: see reference to function template instantiation '_OutIt 
> *std::_Copy_unchecked<_Iter,std::unique_ptr>*>(_InIt,_InIt,_OutIt)'
>  
> being compiled
> 1>  with
> 1>  [
> 1>  
> _OutIt=std::unique_ptr>
>  
> *,
> 1>  
> _Iter=std::unique_ptr>
>  
> *,
> 1>  
> _InIt=std::unique_ptr>
>  
> *
> 1>  ]
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\vector(1142): 
> note: see reference to function template instantiation 'void 
> std::vector>,std::allocator>>>::_Assign_range<_Iter>(_Iter,_Iter,std::forward_iterator_tag)'
>  
> being compiled
> 1>  with
> 1>  [
> 1>  
> _Iter=std::unique_ptr>
>  
> *
> 1>  ]
> 1>  C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\vector(1142): 
> note: see reference to function template instantiation 'void 
> std::vector>,std::allocator>>>::_Assign_range<_Iter>(_Iter,_Iter,std::forward_iterator_tag)'
>  
> being compiled
> 1>  with
> 1>  [
> 1>  
> _Iter=std::unique_ptr>
>  
> *
> 1>  ]
> 1>  C:\Program Files (x86)\Micro

Re: [v8-users] How to retrieve a class defined in a module?

[Ben Ernst]

Thanks for that thought Alex! Drafting a reply to you led me to the answer, 
which is obvious in hindsight.
Yes, I could just get "lamingtons" in this case, but that wouldn't help me 
if it was a non-trivial accessor. In javascript I would be able to call 
"instance.numberOfLamingtons". In this case, I can simply call "Get" with 
value "numberOfLamingtons". Yes, obvious in hindsight. The code ends up 
looking something like the below. Thanks again, thoroughly appreciate the 
help.
Ben


// Call an accessor function on the instance.
v8::Local lamingtons;
CHECK(instance->Get(context, ToV8Value(isolate, 
"numberOfLamingtons")).ToLocal(&lamingtons));
std::cout << ConvertTo(*isolate, 
lamingtons->ToNumber(context).ToLocalChecked()) << std::endl;


On Friday, 27 November 2020 at 23:34:26 UTC+10:30 alex...@gmail.com wrote:

> You wouldn't call it any more than you "call" it in JavaScript. You just 
> get the value via the Object Get function: 
> Local pastries = object->Get(context, String::NewFromUtf8( isolate, 
> "lamingtons").ToLocalChecked());
>
> On Friday, November 27, 2020 at 4:59:00 AM UTC-5 boi...@gmail.com wrote:
>
>> There's one thing I'm struggling with here. Given the simple class 
>> definition below, using the V8 C++ API I can call the ordinary function 
>> "lamingtonsIsUndefined", but how would I call the accessor "get 
>> numberOfLamingtons()"?
>> Many thanks in advance,
>> Ben
>>
>>
>> export class DemonstrationClass {
>> constructor(lamingtons) {
>> this.lamingtons = lamingtons
>> }
>> get numberOfLamingtons() {
>> return this.lamingtons
>> }
>> lamingtonsIsUndefined(){
>> return this.lamingtons === undefined
>> }
>> }
>>
>>
>>
>>
>> On Sunday, 22 November 2020 at 22:14:55 UTC+10:30 Ben Ernst wrote:
>>
>>> Thanks for the advice, that got me back on track. The failure mentioned 
>>> in my original post only occurs when there's nothing at all exported from 
>>> the module. I speculate the namespace object gets garbage collected in that 
>>> situation. When I tested with actual valid modules, everything works fine.
>>> Thanks again,
>>> Ben
>>>
>>>
>>> On Tuesday, 17 November 2020 at 21:21:25 UTC+10:30 Ben Ernst wrote:
>>>
>>>> Thank you for the advice Camillo, the test you referred me to is very 
>>>> helpful. I will prepare a good code sample and come back to this 
>>>> conversation.
>>>>
>>>> Regards,
>>>> Ben
>>>>
>>>>
>>>> On Tue, 17 Nov 2020 at 19:54, Camillo Bruni  
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The ModuleNamespace 
>>>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/include/v8.h;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1;l=1591?q=v8::Module>
>>>>>  
>>>>> object is the proper choice, you can have a look at the existing tests 
>>>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc;l=26235;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1?q=v8::Module>
>>>>> .
>>>>> For future reference, you will usually find (a bit hidden and obscure, 
>>>>> I agree) existing tests in V8's test-api.cc 
>>>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc>
>>>>> .
>>>>>
>>>>> Could you provide some more example code for the error you get 
>>>>> with persistent handles?
>>>>>
>>>>> cheers,
>>>>> Camillo
>>>>>
>>>>> On Tue, 17 Nov 2020 at 01:11, Ben Ernst  wrote:
>>>>>
>>>>>> I am migrating my V8 code from using "plain scripts" to using "ES6 
>>>>>> Modules". There are a few concepts that I am struggling with. 
>>>>>>
>>>>>> First, how might I retrieve a class definition defined in a module? 
>>>>>> Previously I would have used the "global" object on the "context" (i.e. 
>>>>>> context->Global()), and found the class definition there. I can't find a 
>>>>>> good example on how to do that in a module. I am experimenting with 
>>>>>> Module::GetModuleNamespace(), but I'm not sure that I'm on the right 
>>>&g

Re: [v8-users] How to retrieve a class defined in a module?

[Ben Ernst]

There's one thing I'm struggling with here. Given the simple class 
definition below, using the V8 C++ API I can call the ordinary function 
"lamingtonsIsUndefined", but how would I call the accessor "get 
numberOfLamingtons()"?
Many thanks in advance,
Ben


export class DemonstrationClass {
constructor(lamingtons) {
this.lamingtons = lamingtons
}
get numberOfLamingtons() {
return this.lamingtons
}
lamingtonsIsUndefined(){
return this.lamingtons === undefined
}
}




On Sunday, 22 November 2020 at 22:14:55 UTC+10:30 Ben Ernst wrote:

> Thanks for the advice, that got me back on track. The failure mentioned in 
> my original post only occurs when there's nothing at all exported from the 
> module. I speculate the namespace object gets garbage collected in that 
> situation. When I tested with actual valid modules, everything works fine.
> Thanks again,
> Ben
>
>
> On Tuesday, 17 November 2020 at 21:21:25 UTC+10:30 Ben Ernst wrote:
>
>> Thank you for the advice Camillo, the test you referred me to is very 
>> helpful. I will prepare a good code sample and come back to this 
>> conversation.
>>
>> Regards,
>> Ben
>>
>>
>> On Tue, 17 Nov 2020 at 19:54, Camillo Bruni  wrote:
>>
>>> Hi,
>>>
>>> The ModuleNamespace 
>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/include/v8.h;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1;l=1591?q=v8::Module>
>>>  
>>> object is the proper choice, you can have a look at the existing tests 
>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc;l=26235;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1?q=v8::Module>
>>> .
>>> For future reference, you will usually find (a bit hidden and obscure, I 
>>> agree) existing tests in V8's test-api.cc 
>>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc>
>>> .
>>>
>>> Could you provide some more example code for the error you get 
>>> with persistent handles?
>>>
>>> cheers,
>>> Camillo
>>>
>>> On Tue, 17 Nov 2020 at 01:11, Ben Ernst  wrote:
>>>
>>>> I am migrating my V8 code from using "plain scripts" to using "ES6 
>>>> Modules". There are a few concepts that I am struggling with. 
>>>>
>>>> First, how might I retrieve a class definition defined in a module? 
>>>> Previously I would have used the "global" object on the "context" (i.e. 
>>>> context->Global()), and found the class definition there. I can't find a 
>>>> good example on how to do that in a module. I am experimenting with 
>>>> Module::GetModuleNamespace(), but I'm not sure that I'm on the right track.
>>>>
>>>> Second, am I allowed to take a persistent handle to a module? I am 
>>>> finding that after restoring a module from a persistent handle, I 
>>>> encounter 
>>>> the failure below.
>>>>
>>>> #
>>>> # Fatal error in C:\621300de\v8\src/api/api-inl.h, line 128
>>>> # Debug check failed: allow_empty_handle || that != nullptr.
>>>> #
>>>> #
>>>> #
>>>> #FailureMessage Object: 006114FBC2E0
>>>>  C stack trace ===
>>>>
>>>> v8::base::debug::StackTrace::StackTrace 
>>>> [0x0,000,7FF,60D,F82,80B+27]
>>>> v8::platform::DefaultPlatform::PostJob 
>>>> [0x0,000,7FF,60D,F7F,1E1+401]
>>>> V8_Fatal [0x0,000,7FF,60C,251,B87+167]
>>>> v8::base::PrintCheckOperand 
>>>> [0x0,000,7FF,60C,251,683+627]
>>>> v8::Module::GetStatus [0x0,000,7FF,60C,1E0,3FD+141]
>>>> v8::Module::GetModuleNamespace [0x0,000,7FF,60C,1D1,243+19]
>>>>
>>>> -- 
>>>> -- 
>>>> 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-users+u...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/v8-users/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com
>>>>  
>>>> <ht

Re: [v8-users] How to retrieve a class defined in a module?

[Ben Ernst]

Thanks for the advice, that got me back on track. The failure mentioned in 
my original post only occurs when there's nothing at all exported from the 
module. I speculate the namespace object gets garbage collected in that 
situation. When I tested with actual valid modules, everything works fine.
Thanks again,
Ben

On Tuesday, 17 November 2020 at 21:21:25 UTC+10:30 Ben Ernst wrote:

> Thank you for the advice Camillo, the test you referred me to is very 
> helpful. I will prepare a good code sample and come back to this 
> conversation.
>
> Regards,
> Ben
>
>
> On Tue, 17 Nov 2020 at 19:54, Camillo Bruni  wrote:
>
>> Hi,
>>
>> The ModuleNamespace 
>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/include/v8.h;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1;l=1591?q=v8::Module>
>>  
>> object is the proper choice, you can have a look at the existing tests 
>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc;l=26235;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1?q=v8::Module>
>> .
>> For future reference, you will usually find (a bit hidden and obscure, I 
>> agree) existing tests in V8's test-api.cc 
>> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc>
>> .
>>
>> Could you provide some more example code for the error you get 
>> with persistent handles?
>>
>> cheers,
>> Camillo
>>
>> On Tue, 17 Nov 2020 at 01:11, Ben Ernst  wrote:
>>
>>> I am migrating my V8 code from using "plain scripts" to using "ES6 
>>> Modules". There are a few concepts that I am struggling with. 
>>>
>>> First, how might I retrieve a class definition defined in a module? 
>>> Previously I would have used the "global" object on the "context" (i.e. 
>>> context->Global()), and found the class definition there. I can't find a 
>>> good example on how to do that in a module. I am experimenting with 
>>> Module::GetModuleNamespace(), but I'm not sure that I'm on the right track.
>>>
>>> Second, am I allowed to take a persistent handle to a module? I am 
>>> finding that after restoring a module from a persistent handle, I encounter 
>>> the failure below.
>>>
>>> #
>>> # Fatal error in C:\621300de\v8\src/api/api-inl.h, line 128
>>> # Debug check failed: allow_empty_handle || that != nullptr.
>>> #
>>> #
>>> #
>>> #FailureMessage Object: 006114FBC2E0
>>>  C stack trace ===
>>>
>>> v8::base::debug::StackTrace::StackTrace 
>>> [0x0,000,7FF,60D,F82,80B+27]
>>> v8::platform::DefaultPlatform::PostJob 
>>> [0x0,000,7FF,60D,F7F,1E1+401]
>>> V8_Fatal [0x0,000,7FF,60C,251,B87+167]
>>> v8::base::PrintCheckOperand 
>>> [0x0,000,7FF,60C,251,683+627]
>>> v8::Module::GetStatus [0x0,000,7FF,60C,1E0,3FD+141]
>>> v8::Module::GetModuleNamespace [0x0,000,7FF,60C,1D1,243+19]
>>>
>>> -- 
>>> -- 
>>> 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-users+u...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/v8-users/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/v8-users/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> Camillo Bruni |  Software Engineer, V8 |  Google Germany GmbH |  Erika-Mann 
>> Str. 33, 80636 München 
>>
>> Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: 
>> Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>>
>> Diese E-Mail ist vertraulich. Falls Ssie 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 a

Re: [v8-users] How to retrieve a class defined in a module?

[Ben Ernst]

Thank you for the advice Camillo, the test you referred me to is very
helpful. I will prepare a good code sample and come back to this
conversation.

Regards,
Ben


On Tue, 17 Nov 2020 at 19:54, Camillo Bruni  wrote:

> Hi,
>
> The ModuleNamespace
> <https://source.chromium.org/chromium/chromium/src/+/master:v8/include/v8.h;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1;l=1591?q=v8::Module>
> object is the proper choice, you can have a look at the existing tests
> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc;l=26235;drc=5d658083d506ff1bf14abdd2221d94cbcf4fae96;bpv=1;bpt=1?q=v8::Module>
> .
> For future reference, you will usually find (a bit hidden and obscure, I
> agree) existing tests in V8's test-api.cc
> <https://source.chromium.org/chromium/chromium/src/+/master:v8/test/cctest/test-api.cc>
> .
>
> Could you provide some more example code for the error you get
> with persistent handles?
>
> cheers,
> Camillo
>
> On Tue, 17 Nov 2020 at 01:11, Ben Ernst  wrote:
>
>> I am migrating my V8 code from using "plain scripts" to using "ES6
>> Modules". There are a few concepts that I am struggling with.
>>
>> First, how might I retrieve a class definition defined in a module?
>> Previously I would have used the "global" object on the "context" (i.e.
>> context->Global()), and found the class definition there. I can't find a
>> good example on how to do that in a module. I am experimenting with
>> Module::GetModuleNamespace(), but I'm not sure that I'm on the right track.
>>
>> Second, am I allowed to take a persistent handle to a module? I am
>> finding that after restoring a module from a persistent handle, I encounter
>> the failure below.
>>
>> #
>> # Fatal error in C:\621300de\v8\src/api/api-inl.h, line 128
>> # Debug check failed: allow_empty_handle || that != nullptr.
>> #
>> #
>> #
>> #FailureMessage Object: 006114FBC2E0
>>  C stack trace ===
>>
>> v8::base::debug::StackTrace::StackTrace
>> [0x0,000,7FF,60D,F82,80B+27]
>> v8::platform::DefaultPlatform::PostJob
>> [0x0,000,7FF,60D,F7F,1E1+401]
>> V8_Fatal [0x0,000,7FF,60C,251,B87+167]
>> v8::base::PrintCheckOperand
>> [0x0,000,7FF,60C,251,683+627]
>> v8::Module::GetStatus [0x0,000,7FF,60C,1E0,3FD+141]
>> v8::Module::GetModuleNamespace [0x0,000,7FF,60C,1D1,243+19]
>>
>> --
>> --
>> 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/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com
>> <https://groups.google.com/d/msgid/v8-users/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> Camillo Bruni |  Software Engineer, V8 |  Google Germany GmbH |  Erika-Mann
> Str. 33, 80636 München
>
> Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft:
> Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
> Diese E-Mail ist vertraulich. Falls Ssie 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/CAOeS1i9mEbcpxGQr1uNk%3DfAMPDi%2Bz%2Bzkun0eiopfphqErJJLAQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/v8-users/CAOeS1i9mEbcpxGQr1uNk%3DfAMPDi%2Bz%2Bzkun0eiopfphqErJJLAQ%40mail.gmail.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/CABexdQ72DiZqEmCwo-48QL095%3Dgbw5FZ%2BJcvjfy%3D0GvTwZuBPA%40mail.gmail.com.

[v8-users] Re: Link failed with error " undefined reference to 'std::__1::__.... "

[Ben Ernst]

This may not be very helpful, I work on Windows, but you may find that if 
you "use_custom_libcxx = false", you also have to "use_clang=false". This 
seems to be the case on Windows.
Ben

On Sunday, 15 November 2020 at 02:17:34 UTC+10:30 tie.s...@gmail.com wrote:

> Version: <8.0>
> OS: 
> Architecture: 
>
> Link failed with errors as below:
>
> [1/1] LINK ./d8
>
> FAILED: d8 exe.unstripped/d8 exe.unstripped/d8.map.gz 
>
> python "../../build/toolchain/gcc_link_wrapper.py" --output="./d8" 
> --strip="../../buildtools/third_party/eu-strip/bin/eu-strip" 
> --unstripped-file="./exe.unstripped/d8" --map-file 
> "./exe.unstripped/d8.map.gz" -- 
> ../../third_party/llvm-build/Release+Asserts/bin/clang++ 
> -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack 
> -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=gold 
> -Wl,--icf=all -Wl,--exclude-libs=libgcc.a 
> -Wl,--exclude-libs=libvpx_assembly_arm.a --target=aarch64-linux-android21 
> -Wl,-mllvm,-enable-machine-outliner=never 
> --sysroot=../../third_party/android_ndk/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>  
> -B../../third_party/android_ndk/toolchains/llvm/prebuilt/darwin-x86_64 
> -Wl,--warn-shared-textrel -pie -Bdynamic -Wl,-z,nocopyreloc 
> -Wl,--warn-shared-textrel -Wl,-O2 -Wl,--gc-sections -o 
> "./exe.unstripped/d8" -Wl,--start-group @"./d8.rsp"  -Wl,--end-group  -ldl 
> -lm -llog
>
> ../../third_party/android_ndk/toolchains/llvm/prebuilt/darwin-x86_64/lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld.gold:
>  
> warning: cannot find entry symbol 'nable-machine-outliner=never'
>
> obj/d8/d8-platforms.o:d8-platforms.cc:function 
> std::__1::__shared_weak_count::__release_shared(): error: undefined 
> reference to 'std::__1::__shared_weak_count::__release_weak()'
>
> obj/d8/d8.o:d8.cc:function std::__1::pair std::__1::char_traits, std::__1::allocator > const, 
> std::__1::unique_ptr std::__1::default_delete > >::~pair(): error: 
> undefined reference to 'std::__1::basic_string std::__1::char_traits, std::__1::allocator >::~basic_string()'
>
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> ninja: build stopped: subcommand failed.
>
> And here is args.gn:
> ==
> is_debug = false
> is_component_build = false
> target_os = "android"
> target_cpu = "arm64"
> v8_target_cpu = "arm64"
> v8_use_external_startup_data=false
> v8_enable_handle_zapping=false
> v8_monolithic=true
> is_official_build=true
> v8_enable_i18n_support=false
> v8_untrusted_code_mitigations=false
> use_custom_libcxx = false
> use_thin_lto = false
> v8_enable_lite_mode = true
> v8_enable_wasm = false
> v8_enable_debugger = false
> v8_enable_minor_mc = false
> symbol_level = 0
> use_lld = false
> clang_use_chrome_plugins = false
> ===
>
> Thanks for help!
>
> *Best regards!*
>

-- 
-- 
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/fbd333e0-a055-4839-9711-3615f07d5e5fn%40googlegroups.com.

[v8-users] How to retrieve a class defined in a module?

[Ben Ernst]

I am migrating my V8 code from using "plain scripts" to using "ES6 
Modules". There are a few concepts that I am struggling with. 

First, how might I retrieve a class definition defined in a module? 
Previously I would have used the "global" object on the "context" (i.e. 
context->Global()), and found the class definition there. I can't find a 
good example on how to do that in a module. I am experimenting with 
Module::GetModuleNamespace(), but I'm not sure that I'm on the right track.

Second, am I allowed to take a persistent handle to a module? I am finding 
that after restoring a module from a persistent handle, I encounter the 
failure below.

#
# Fatal error in C:\621300de\v8\src/api/api-inl.h, line 128
# Debug check failed: allow_empty_handle || that != nullptr.
#
#
#
#FailureMessage Object: 006114FBC2E0
 C stack trace ===

v8::base::debug::StackTrace::StackTrace [0x0,000,7FF,60D,F82,80B+27]
v8::platform::DefaultPlatform::PostJob [0x0,000,7FF,60D,F7F,1E1+401]
V8_Fatal [0x0,000,7FF,60C,251,B87+167]
v8::base::PrintCheckOperand 
[0x0,000,7FF,60C,251,683+627]
v8::Module::GetStatus [0x0,000,7FF,60C,1E0,3FD+141]
v8::Module::GetModuleNamespace [0x0,000,7FF,60C,1D1,243+19]

-- 
-- 
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/6e1f91bb-9d1b-4e3e-b772-c1cdf71afb06n%40googlegroups.com.

Re: [v8-users] v8::ScriptOrigin line/column offset

[Ben Ernst]

Yes that's right, when a debugger or an error message says you're on line X
and column Y, it deducts the values you specify in the offsets. So if you
transform user's code in some form, the error messages can be adjusted to
still have the right line numbers and column numbers.



On Fri, 13 Nov 2020 at 00:43, Bit Cortex  wrote:

> Thanks, but what's the actual effect of setting the line or column offset
> to a nonzero value?
>
> Based on your description, I'd guess that it might affect stack traces and
> possibly debugging.
>
> Can someone confirm that? Or do I not understand correctly?
>
> On Wednesday, November 11, 2020 at 5:05:50 PM UTC-5 Ben Noordhuis wrote:
>
>> On Wed, Nov 11, 2020 at 9:26 PM Bit Cortex  wrote:
>> >
>> > Hello!
>> >
>> > Could someone describe the purpose of the line and column offset
>> properties of v8::ScriptOrigin? What effect do nonzero values have?
>> >
>> > Thanks!
>>
>> I believe they're intended to offset IIFEs[1] and other wrappers that
>> embedders may want to add around the user's script code.
>>
>> [https://en.wikipedia.org/wiki/Immediately-invoked_function_expression]
>>
> --
> --
> 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/f9f3c898-d022-48d9-b14b-d670731b8008n%40googlegroups.com
> 
> .
>

-- 
-- 
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/CABexdQ5hh4Ez1yMvcMNBT%2BMHxKangM6qr8Oi8M7SH%3D_RDtq5rQ%40mail.gmail.com.

Re: [v8-users] Re: Upgrading v8 from 7.4 to 8.5

[Ben Ernst]

Vinayaka, the answer is here in your console output.

# Fatal error in HandleScope::HandleScope
# Entering the V8 API without proper locking in place
#

You want to use v8::Locker consistently, pretty much wherever you have a
HandleScope you need to instantiate a v8::Locker immediately before.

Regards,
Ben

On Tue, 3 Nov 2020 at 16:46, Vinayaka Kamath 
wrote:

> I have attached the stack trace from attaching the debugger to the running
> program below:
>
>
> https://drive.google.com/drive/folders/124iiIB682-vgbN5S0BPG2mR2DmUe32lc?usp=sharing
> On Tuesday, November 3, 2020 at 10:49:21 AM UTC+5:30 Vinayaka Kamath wrote:
>
>> Hello All,
>>
>> I am involved with a project that relies on v8 for most of its features.
>> We are trying to upgrade the v8 engine to 8.5 and the project compiles
>> without any error.
>>
>> We also have a debugger that uses inspector protocol -- however after the
>> upgradation the debugger crashes when 
>> *session_->dispatchProtocolMessage(message);
>> *is invoked.
>>
>> I am relatively new to v8 and don't understand it completely, however I
>> noticed that the implementation of platform, return values of Set, Get were
>> changed between the versions(and the corresponding changes are made). I
>> don't see any changes with respect to the inspector -- I am afraid I am
>> missing something here.
>>
>> You can find our project here:
>> https://github.com/couchbase/eventing/tree/master/third_party/inspector
>>
>> Any help would be very much appreciated!
>>
>> The debugger crashes with the following message:
>> ==
>> # Fatal error in HandleScope::HandleScope
>> # Entering the V8 API without proper locking in place
>> #
>> == Minidump location: crash/cfecbc18-15f2-428d-a10256ac-40061e00.dmp
>> Status: 1 ==
>> Failed to read from stderr pipe, err: EOF
>> Failed to read from stdout pipe, err: EOF
>> Exiting c++ debug worker with error: signal: illegal instruction
>> ===
>>
>> Also the symbols in the coredump (after conversion from minidump to
>> coredump) is not getting resolved. I see ? for line numbers and
>> function names!
>>
>> --
> --
> 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/6e4e4a0c-b446-471b-8076-04afb2b3f5cen%40googlegroups.com
> 
> .
>

-- 
-- 
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/CABexdQ4Rgt-VX6BpCnGOtTmpX5c--G6b-oHPNxqxxO8i%2B2NFtQ%40mail.gmail.com.

Re: [v8-users] Enable pointer compression V8 8.6

[Ben Ernst]

Thank you Rodrigo, defining V8_COMPRESS_POINTERS was indeed the fix (future 
readers of this thread note double "S"). 
Cheers,
Ben

On Sunday, 25 October 2020 at 12:24:29 UTC+10:30 Rodrigo Hernandez wrote:

> Hi Ben, 
>
> You need to add - DV8_COMPRES_POINTERS to your compile flags.
>
>
>
>
> On Sat, Oct 24, 2020, 7:06 PM Ben Ernst  wrote:
>
>> Hey all, thank you in advance for any advice here. How does one enable 
>> pointer compression? I'm updating from v7.1 to v8.6, and I get this error 
>> message (below) at runtime. It is probably something minor I overlooked in 
>> the code samples.
>>
>>
>>
>> #
>> # Fatal error in ../../src/api/api.cc, line 5696
>> # Embedder-vs-V8 build configuration mismatch. On embedder side pointer 
>> compression is DISABLED while on V8 side it's ENABLED.
>> #
>> #
>> #
>> #FailureMessage Object: 0078F51FF0A0
>>  C stack trace ===
>>
>> v8::base::debug::StackTrace::StackTrace [0x7FF77D4C776B+27]
>> v8::platform::DefaultPlatform::PostJob [0x7FF77D4C4141+401]
>> V8_Fatal [0x7FF77B7A5787+167]
>> v8::V8::Initialize [0x7FF77B73D78D+77]
>> v8::V8::Initialize [0x7FF77B545CE0+176] 
>> (C:\Code\Optimatics\justobjects\libs\3rdParty\include\v8.h:9655)
>> ezv8::Platform::Impl::Impl [0x7FF77B54BBC3+259] 
>> (C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:46)
>> std::_Construct_in_place 
>> [0x7FF77D4A9AB2+98] (C:\Program Files (x86)\Microsoft Visual 
>> Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\xmemory:231)
>> 
>> std::_Ref_count_obj2::_Ref_count_obj2<>
>>  
>> [0x7FF77D4A9637+119] (C:\Program Files (x86)\Microsoft Visual 
>> Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\memory:1428)
>> std::make_shared [0x7FF77B54B9F8+120] 
>> (C:\Program Files (x86)\Microsoft Visual 
>> Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\memory:2072)
>> ezv8::Platform::Platform [0x7FF77D4AA585+69] 
>> (C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:24)
>> `dynamic initializer for 'platform'' [0x7FF77B52CBB7+71] 
>> (C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:70)
>>
>> -- 
>> -- 
>> 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-users+u...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/v8-users/a0e1506d-5f78-4265-b7de-0a5de957f8f6n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/v8-users/a0e1506d-5f78-4265-b7de-0a5de957f8f6n%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/6fa133f7-9894-4cf2-bdda-f8ba7681e5d9n%40googlegroups.com.

[v8-users] Enable pointer compression V8 8.6

[Ben Ernst]

Hey all, thank you in advance for any advice here. How does one enable 
pointer compression? I'm updating from v7.1 to v8.6, and I get this error 
message (below) at runtime. It is probably something minor I overlooked in 
the code samples.



#
# Fatal error in ../../src/api/api.cc, line 5696
# Embedder-vs-V8 build configuration mismatch. On embedder side pointer 
compression is DISABLED while on V8 side it's ENABLED.
#
#
#
#FailureMessage Object: 0078F51FF0A0
 C stack trace ===

v8::base::debug::StackTrace::StackTrace [0x7FF77D4C776B+27]
v8::platform::DefaultPlatform::PostJob [0x7FF77D4C4141+401]
V8_Fatal [0x7FF77B7A5787+167]
v8::V8::Initialize [0x7FF77B73D78D+77]
v8::V8::Initialize [0x7FF77B545CE0+176] 
(C:\Code\Optimatics\justobjects\libs\3rdParty\include\v8.h:9655)
ezv8::Platform::Impl::Impl [0x7FF77B54BBC3+259] 
(C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:46)
std::_Construct_in_place 
[0x7FF77D4A9AB2+98] (C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\xmemory:231)

std::_Ref_count_obj2::_Ref_count_obj2<>
 
[0x7FF77D4A9637+119] (C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\memory:1428)
std::make_shared [0x7FF77B54B9F8+120] 
(C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\memory:2072)
ezv8::Platform::Platform [0x7FF77D4AA585+69] 
(C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:24)
`dynamic initializer for 'platform'' [0x7FF77B52CBB7+71] 
(C:\Code\Optimatics\justobjects\src\ezv8\platform.cpp:70)

-- 
-- 
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/a0e1506d-5f78-4265-b7de-0a5de957f8f6n%40googlegroups.com.

Re: [v8-users] Recovering a FunctionTemplate (or how to ->Inherit from one you've lost the handle to?)

[Ben Ernst]

I work with embedded V8, not with node, so some of that is french to me :)
I tried storing FunctionTemplate in a Value and encountered the same error.
If you're keeping the persistent handles in a global collection in any 
case, you might consider taking a raw pointer to the Persistent, and 
storing that in a v8::External. Then you can static_cast it back to 
FunctionTemplate where you call "Inherit". It still means you're doing some 
deliberate garbage handling however.

On Friday, 23 October 2020 at 06:35:07 UTC+10:30 Rodrigo Hernandez wrote:

> Hi Ben,
>
> Yes, however what I need to store is the v8::FunctionTemplate, 
> v8::Local to be more specific, which does not inherit 
> from Value and there is a static_assert that checks for that.
>
> So perhaps, maybe if go to the real problem a different solution may arise.
>
> I have a Js wrapper C++ base class from which all C++-to-Js must inherit, 
> this is based on the code for Node.js, so when I write a new class that 
> inherits from this wrapper, I need to allocate a FunctionTemplate on the 
> isolate/context pair, like so:
>
> I removed some lines, but otherwise you can look at this code here: 
> https://github.com/AeonGames/AeonGUI/blob/master/core/dom/EventTarget.cpp#L23
>
> void EventTarget::Initialize ( v8::Isolate* aIsolate )
> {
> v8::Local context = aIsolate->GetCurrentContext();
> //---
> // Store constructor on a callback data object
>
> v8::Local constructor_data_template = 
> v8::ObjectTemplate::New ( aIsolate );
> constructor_data_template->SetInternalFieldCount ( 1 );
> v8::Local constructor_data =
>
> constructor_data_template->NewInstance ( context 
> ).ToLocalChecked();
>
> // Prepare EventTarget constructor template
> v8::Local constructor_template = 
> v8::FunctionTemplate::New ( aIsolate, JsObjectWrap::New, 
> constructor_data ); 
> // <- THIS IS THE FunctionTemplate I NEED TO STORE
>
> constructor_template->SetClassName ( v8::String::NewFromUtf8 ( 
> aIsolate, "EventTarget" ).ToLocalChecked() );
>
> constructor_template->InstanceTemplate()->SetInternalFieldCount ( 1 );
>
> 
> AddFunctionTemplate ( aIsolate, typeid ( EventTarget ), constructor_template 
> ); 
> // < THIS IS MY CURRENT SOLUTION
>
> //
>
>
> v8::Local event = event_template->GetFunction ( context 
> ).ToLocalChecked();
> context->Global()->Set ( context, v8::String::NewFromUtf8 (
>  aIsolate, "Event" ).ToLocalChecked(),
>  event ).FromJust();
>
>
> v8::Local constructor = 
> constructor_template->GetFunction ( context ).ToLocalChecked();
> constructor_data->SetInternalField ( 0, constructor );
> context->Global()->Set ( context, v8::String::NewFromUtf8 (
>
>  aIsolate, "EventTarget" 
> ).ToLocalChecked(),
>  constructor ).FromJust();
> }
>
> Then, when I want to have Node inherit from EventTarget I write a similar 
> static function (the previous one is also static)
> https://github.com/AeonGames/AeonGUI/blob/master/core/dom/Node.cpp#L221
>
> void Node::Initialize ( v8::Isolate* aIsolate )
> {
> if ( HasFunctionTemplate ( aIsolate, typeid ( Node ) ) )
> {
> throw std::runtime_error ( "Isolate already initialized." );
> }
>
> v8::Local context = aIsolate->GetCurrentContext();
>
> // Prepare Node constructor template
>
> v8::Local constructor_template = 
> v8::FunctionTemplate::New ( aIsolate );
>
> constructor_template->SetClassName ( v8::String::NewFromUtf8 ( 
> aIsolate, "Node" ).ToLocalChecked() );
> constructor_template->Inherit ( EventTarget::GetFunctionTemplate ( 
> aIsolate, typeid ( EventTarget ) ) ); 
> // <-- THIS IS WHAT I REALLY NEED
>
>
> AddFunctionTemplate ( aIsolate, typeid ( Node ), constructor_template 
> );
>
>
> v8::Local constructor = 
> constructor_template->GetFunction ( context ).ToLocalChecked();
> context->Global()->Set ( context, v8::String::NewFromUtf8 (
>  aIsolate, "Node" ).ToLocalChecked(),
>  constructor ).FromJust();
> }
>
> As I said before, this works but I feel that makes the code too verbose 
> and prone to error, for example now I am now forced to have a trivial 
> Finalize function on all classes:
>
> void Node::Finalize ( v8::Isolate* aIsolate )
> {
> RemoveFunctionTemplate ( aIsolate, typeid ( Node ) );
> }
>
> because the FunctionTemplate objects are stored as Persistent Handles in 
> this map:
>
>
> static std::unordered_map, 
> v8::Persistent v8::CopyablePersistentTraits>> FunctionTemplates{};
>
> So I need to free them all, unlike a 

[v8-users] Re: Errors Building v8 8.3.110.13 for Windows with is_component_build=true target_cpu="x64" is_clang=false use_custom_libcxx=false

[Ben Ernst]

Thanks, that'll be helpful.

On Friday, 23 October 2020 at 06:46:47 UTC+10:30 Rodrigo Hernandez wrote:

> I almost forgot, I created this repo for my own sanity:
>
> https://github.com/AeonGames/v8-builder
>
> it has bash scripts to make generating patches for new versions easier... 
> or at least for me 😁
>
>
> On Thursday, October 22, 2020 at 2:12:47 PM UTC-6 Rodrigo Hernandez wrote:
>
>> Latest is  8.5.210.20 , there is a PR at 
>> https://github.com/microsoft/vcpkg/pull/13355 that is ready to merge but 
>> I guess got neglected.
>>
>> you can grab the patches from there, I have not made a push upstream 
>> because I really needed a break from v8 building, and because my latest 
>> changes
>> include a new toolchain for MinGW-w64 and are not so trivial.
>>
>> Let me know if there's something else I can help with.
>>
>> On Wednesday, October 21, 2020 at 5:34:49 PM UTC-6 boi...@gmail.com 
>> wrote:
>>
>>> What version of V8 did this change go into? I built 8.6 yesterday, but 
>>> still get the below error at linking, I thought I might try going back to 
>>> whatever version you successfully used.
>>>
>>> 1>platform.obj : error LNK2019: unresolved external symbol "class 
>>> std::unique_ptr>> v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum 
>>> v8::platform::IdleTaskSupport,enum 
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct std::default_delete>> v8::TracingController> >)" 
>>> (?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)
>>> 1>C:\Code\Optimatics\justobjects\src\x64\Debug\ezv8.dll : fatal error 
>>> LNK1120: 1 unresolved externals
>>>
>>>
>>>
>>> On Wednesday, 5 August 2020 at 07:53:41 UTC+9:30 kosit la-orngsri wrote:
>>>
 สวัสดี

 ในวันที่ วันพุธที่ 5 สิงหาคม ค.ศ. 2020 เวลา 0 นาฬิกา 59 นาที 57 วินาที 
 UTC+7 Rodrigo Hernandez เขียนว่า:

>
> A PR for the vcpkg port is up at:
>
> https://github.com/microsoft/vcpkg/pull/12687
>
> Just working out the final issues with x86-windows.
>
>
> On Thursday, July 9, 2020 at 2:06:21 PM UTC-6, Rodrigo Hernandez wrote:
>
>> Hello,
>>
>> I am trying to create a VCPKG (https://github.com/microsoft/vcpkg) 
>> port of v8,
>> and in doing so I am syncing to tag 8.3.110.13 as suggested here: 
>> https://v8.dev/docs/version-numbers
>>
>> Since this is package manager, I want to build against msvc's c++ 
>> lib, so I am using use_custom_libcxx=false,
>> however I am seeing linking errors related to undefined symbols on 
>> debug builds like:
>>
>> [1797/2086] LINK(DLL) v8.dll v8.dll.lib v8.dll.pdb
>> FAILED: v8.dll v8.dll.lib v8.dll.pdb 
>> C:/Code/vcpkg/buildtrees/v8/src/epot_tools-f6c91d5fca/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
>>  
>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 
>> False link.exe /nologo /IMPLIB:./v8.dll.lib /DLL /OUT:./v8.dll 
>> /PDB:./v8.dll.pdb @./v8.dll.rsp
>> class-verifiers-tq.obj : error LNK2019: unresolved external symbol 
>> "public: class v8::internal::TNode __cdecl 
>> v8::internal::TorqueGeneratedExportedMacrosAssembler::IsFastJSArray(class
>>  
>> v8::internal::TNode,class 
>> v8::internal::TNode)" 
>> (?IsFastJSArray@TorqueGeneratedExportedMacrosAssembler@internal@v8@@QEAA?AV?$TNode@UBoolT@internal@v8@@@23@V?$TNode@VObject@internal@v8@@@23@V?$TNode@VContext@internal@v8@@@23@@Z)
>>  
>> referenced in function "public: class v8::internal::TNode> v8::internal::JSArray> __cdecl 
>> v8::internal::CodeStubAssembler::TaggedToFastJSArray(class 
>> v8::internal::TNode,class 
>> v8::internal::TNode,class 
>> v8::internal::compiler::CodeAssemblerLabel *)" 
>> (?TaggedToFastJSArray@CodeStubAssembler@internal@v8@@QEAA?AV?$TNode@VJSArray@internal@v8@@@23@V?$TNode@VContext@internal@v8@@@23@V?$TNode@VObject@internal@v8@@@23@PEAVCodeAssemblerLabel@compiler@23@@Z)
>>
>> There's 75 symbols missing in total, all in class-verifiers-tq.obj, I 
>> can post the rest if needed, but hopefully this will give you an idea.
>>
>> On release builds there is only one undefined symbol: void __cdecl 
>> v8::internal::FixedArray::set(int,class v8::internal::Smi), which I 
>> believe 
>> should be in fixed-array-tq-csa.obj,
>> but it is not there. There are 2 overrides right next to its 
>> definition in fixed-array-inl.h that do seem to exist in the object file 
>> but this one isn't.
>>
>> here is the error output:
>>
>> ninja: Entering directory `out\x64.release'
>> [1/298] LINK mksnapshot.exe 

Re: [v8-users] Recovering a FunctionTemplate (or how to ->Inherit from one you've lost the handle to?)

[Ben Ernst]

Rodrigo, you should be able to trivially cast a v8::Function or v8::Object 
to v8::Value is that what you're trying to do? In that case you don't need 
to put them in a v8::External. You can pass those objects to 
data->SetInternalField safely I would think.
Ben

On Tuesday, 20 October 2020 at 15:10:00 UTC+10:30 Rodrigo Hernandez wrote:

> So, coming back to this, is there a way to cast/convert/wrap a local 
> template (function or object) into a v8::Value?
> I am thinking about hiding them inside an internal field so I could do:
>
> context->global()->GetFunction("constructor")->GetInternalField(X).
>
> how safe would it be to cast them to a void* and wrapping them inside a 
> v8::External?
>
> On Sunday, October 11, 2020 at 11:40:27 AM UTC-6 Rodrigo Hernandez wrote:
>
>> Thanks Ben, I see how those are less optimal, I was hoping for something 
>> along the lines of context->global()->GetFunctionTemplate("constructor"), 
>> or something along those lines.
>> The only problem I have with my approach is that I need a Finalize 
>> function on each wrapped class that pretty much just resets the permanent 
>> handles.
>>
>> Thanks Again!
>> On Sunday, October 11, 2020 at 1:49:10 AM UTC-6 Ben Noordhuis wrote:
>>
>>> On Sat, Oct 10, 2020 at 10:44 PM Rodrigo Hernandez 
>>>  wrote: 
>>> > 
>>> > Hello, 
>>> > 
>>> > So, suppose I am wrapping a C++ class around a JS constructor, I've 
>>> already created and initialized the isolate, created and initialized a 
>>> context, I have the FunctionTemplate for the constructor and I have 
>>> instantiated the function and I can call it from Js as x() or new X(), 
>>> > all this is fine, the function template context is finished and the 
>>> handle lost. 
>>> > 
>>> > But then I want to create another wrapped object for a class that 
>>> inherits from the first one. 
>>> > Is there a way to retrieve the base class FunctionTemplate so in the 
>>> child class I can call child->Inherit(base)? 
>>> > 
>>> > Is there another way of doing this? 
>>> > 
>>> > Right now I am keeping a C++ unordered_map of isolate to persistent 
>>> handle to function templates, and that works, but is that the only option? 
>>> > 
>>> > Thanks! 
>>>
>>> It's not the only option but it's a pretty good solution. Less optimal 
>>> solutions: 
>>>
>>> - store them in the snapshot with SnapshotCreator::AddData() (but you 
>>> can only retrieve it once) 
>>> - scan the heap for them with Isolate::VisitHandlesWithClassIds(). 
>>>
>>> No doubt there are more ways to stow them away somewhere. 
>>>
>>

-- 
-- 
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/3496e4c4-cf66-42ae-b517-86ac95431901n%40googlegroups.com.

[v8-users] Re: Errors Building v8 8.3.110.13 for Windows with is_component_build=true target_cpu="x64" is_clang=false use_custom_libcxx=false

[Ben Ernst]

What version of V8 did this change go into? I built 8.6 yesterday, but 
still get the below error at linking, I thought I might try going back to 
whatever version you successfully used.

1>platform.obj : error LNK2019: unresolved external symbol "class 
std::unique_ptr > __cdecl v8::platform::NewDefaultPlatform(int,enum 
v8::platform::IdleTaskSupport,enum 
v8::platform::InProcessStackDumping,class std::unique_ptr >)" 
(?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)
1>C:\Code\Optimatics\justobjects\src\x64\Debug\ezv8.dll : fatal error 
LNK1120: 1 unresolved externals



On Wednesday, 5 August 2020 at 07:53:41 UTC+9:30 kosit la-orngsri wrote:

> สวัสดี
>
> ในวันที่ วันพุธที่ 5 สิงหาคม ค.ศ. 2020 เวลา 0 นาฬิกา 59 นาที 57 วินาที 
> UTC+7 Rodrigo Hernandez เขียนว่า:
>
>>
>> A PR for the vcpkg port is up at:
>>
>> https://github.com/microsoft/vcpkg/pull/12687
>>
>> Just working out the final issues with x86-windows.
>>
>>
>> On Thursday, July 9, 2020 at 2:06:21 PM UTC-6, Rodrigo Hernandez wrote:
>>
>>> Hello,
>>>
>>> I am trying to create a VCPKG (https://github.com/microsoft/vcpkg) port 
>>> of v8,
>>> and in doing so I am syncing to tag 8.3.110.13 as suggested here: 
>>> https://v8.dev/docs/version-numbers
>>>
>>> Since this is package manager, I want to build against msvc's c++ lib, 
>>> so I am using use_custom_libcxx=false,
>>> however I am seeing linking errors related to undefined symbols on debug 
>>> builds like:
>>>
>>> [1797/2086] LINK(DLL) v8.dll v8.dll.lib v8.dll.pdb
>>> FAILED: v8.dll v8.dll.lib v8.dll.pdb 
>>> C:/Code/vcpkg/buildtrees/v8/src/epot_tools-f6c91d5fca/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
>>>  
>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 
>>> False link.exe /nologo /IMPLIB:./v8.dll.lib /DLL /OUT:./v8.dll 
>>> /PDB:./v8.dll.pdb @./v8.dll.rsp
>>> class-verifiers-tq.obj : error LNK2019: unresolved external symbol 
>>> "public: class v8::internal::TNode __cdecl 
>>> v8::internal::TorqueGeneratedExportedMacrosAssembler::IsFastJSArray(class 
>>> v8::internal::TNode,class 
>>> v8::internal::TNode)" 
>>> (?IsFastJSArray@TorqueGeneratedExportedMacrosAssembler@internal@v8@@QEAA?AV?$TNode@UBoolT@internal@v8@@@23@V?$TNode@VObject@internal@v8@@@23@V?$TNode@VContext@internal@v8@@@23@@Z)
>>>  
>>> referenced in function "public: class v8::internal::TNode>> v8::internal::JSArray> __cdecl 
>>> v8::internal::CodeStubAssembler::TaggedToFastJSArray(class 
>>> v8::internal::TNode,class 
>>> v8::internal::TNode,class 
>>> v8::internal::compiler::CodeAssemblerLabel *)" 
>>> (?TaggedToFastJSArray@CodeStubAssembler@internal@v8@@QEAA?AV?$TNode@VJSArray@internal@v8@@@23@V?$TNode@VContext@internal@v8@@@23@V?$TNode@VObject@internal@v8@@@23@PEAVCodeAssemblerLabel@compiler@23@@Z)
>>>
>>> There's 75 symbols missing in total, all in class-verifiers-tq.obj, I 
>>> can post the rest if needed, but hopefully this will give you an idea.
>>>
>>> On release builds there is only one undefined symbol: void __cdecl 
>>> v8::internal::FixedArray::set(int,class v8::internal::Smi), which I believe 
>>> should be in fixed-array-tq-csa.obj,
>>> but it is not there. There are 2 overrides right next to its definition 
>>> in fixed-array-inl.h that do seem to exist in the object file but this one 
>>> isn't.
>>>
>>> here is the error output:
>>>
>>> ninja: Entering directory `out\x64.release'
>>> [1/298] LINK mksnapshot.exe mksnapshot.exe.pdb
>>> FAILED: mksnapshot.exe mksnapshot.exe.pdb
>>> C:/Code/vcpkg/buildtrees/v8/src/epot_tools-f6c91d5fca/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
>>>  
>>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 
>>> False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb 
>>> @./mksnapshot.exe.rsp
>>> exported-macros-assembler-tq.obj : error LNK2019: unresolved external 
>>> symbol "public: void __cdecl v8::internal::FixedArray::set(int,class 
>>> v8::internal::Smi)" (?set@FixedArray@internal@v8@@QEAAXHVSmi@23@@Z) 
>>> referenced in function "protected: void __cdecl 
>>> v8::internal::OrderedHashTable>> v8::internal::OrderedHashMap,2>::SetNumberOfBuckets(int)" 
>>> (?SetNumberOfBuckets@?$OrderedHashTable@VOrderedHashMap@internal@v8@@$01@internal@v8@@IEAAXH@Z)
>>>
>>> .\mksnapshot.exe : fatal error LNK1120: 1 unresolved externals
>>>
>>> Is there something I can patch to make this work? is this a known issue?
>>>
>>> Also, is there a way to add a debug postfix/suffix like "d" to debug 
>>> libraries?
>>>
>>> Thanks in advance!
>>>
>>

-- 
-- 
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 Group

Re: [v8-users] Re: Errors Building v8 8.3.110.13 for Windows with is_component_build=true target_cpu="x64" is_clang=false use_custom_libcxx=false

[Ben Ernst]

Rodrigo, what's your project? I tried and failed to fix this build, I'd
happily throw a few hundred dollars in gratitude at anyone able to get it
working stably. I wonder if there might be other users out there in the
same boat.
Ben



On Fri, 17 Jul 2020 at 03:40, Rodrigo Hernandez <
kwizatz.aeongames@gmail.com> wrote:

>
> Ok, found the problem, beside some missing V8_PRIVATE_EXPORTs,
> v8_enable_verify_heap is broken on component builds.
>
> v8_enable_verify_heap is enabled by is_debug, and it causes
> the VERIFY_HEAP define to be added to the compilation flags,
> gen\torque-generated\class-verifiers-tq.cc (Not sure which .tq file
> generates this one) has a file wide guard for this VERIFY_HEAP define, so
> even if compiled, if not set, produces no code.
>
> The problem then is that functions inside class-verifiers-tq.cc reference
> functions in v8_initializers, which is a dependency ONLY exposed in
> v8_for_testing (and v8_init, but that's not a lib).
>
> Since I doubt verify heap is intended for test only targets, I guess
> functions in class-verifiers-tq.cc should not be calling anything in
> v8_initializers.
>
> Either way adding v8_enable_verify_heap=false (even if you have
> is_debug=true) to the args removes those cryptic undefined symbol errors.
>
>
> On Tuesday, July 14, 2020 at 11:50:03 AM UTC-6, Rodrigo Hernandez wrote:
>>
>>
>> Got to the same point with branch head 8.1, did some dependency moves
>> like adding v8_initializers as a v8 dependency as well as wasm_api_test as
>> well as adding some missing V8_EXPORT macros until I got to the point where
>> NodeCache was undefined,
>> moved more deps and got duplicated symbols.
>>
>> Somehow I don't think adding the deps is what's missing, the symbols
>> should be there somewhere or the clang build would fail as well, but it
>> doesn't, I think it has to do with either the assembly generation or
>> something that was left undone when wee8 was added.
>>
>> I have patches for building with MSYS + MinGW64, and none of these issues
>> showed up when writing those, so there must be something GCC/CLANG is doing
>> that MSVC is not doing yet.
>>
>> I need to drop this project until the weekend, I'll come back try to
>> figure out what am I missing then, in the meantime, any hints of what could
>> be going on are welcome.
>>
>> Thanks again.
>>
> --
> --
> 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/20e44a86-a777-4291-a663-ed8c52fd7d35o%40googlegroups.com
> 
> .
>

-- 
-- 
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/CABexdQ6%2B9ZAFKXnh6MBjUK%2BkzutNOpfJ9-mhjC3%2BmK2iiYf9fw%40mail.gmail.com.

Re: [v8-users] Re: Errors Building v8 8.3.110.13 for Windows with is_component_build=true target_cpu="x64" is_clang=false use_custom_libcxx=false

[Ben Ernst]

Rodrigo, you might have more luck with the latest 8.1 tag (rather than
8.3), I recall that 8.1 is building OK with MSVC. If you're writing a vcpkg
port, settling for a clang build might not be ideal, since MSVC programs
won't be able to reliably link to it.
Ben

On Mon, 13 Jul 2020, 2:17 am Rodrigo Hernandez, <
kwizatz.aeongames@gmail.com> wrote:

>
> Ok, findings so far:
>
> commenting out the flag "/Zc:inline" in build/config/compiler/BUILD.gn
> takes care of the FixedArray::set undefined symbol, but the build takes
> longer, need to see if bumping "/Ob" from "/Ob2" to "/Ob3" fixes the issue
> w/o removing the inline flag.
>
> After that, both builds (debug/release) get to the same place, 73
> unresolved symbols at v8.dll link stage, all seem to be part of the
> v8_initializers source set which is a dep of the v8_for_testing component
> but not for the v8 one.
> I tried adding the dependency but no luck, seems the linker doesn't take
> the files into account, or I did something wrong, not sure, still I doubt
> that is the proper solution since the clang/customc++ build.is fine.
>
> I also tried the clang build with system libc++, that produces compiling
> errors that were relatively easy to solve, adding the compiler flags
> "-Wno-invalid-offsetof" and "-Wno-range-loop-construct" should do the work,
> however with that last one
> still saw the compiler complain because of some for(auto x: map) loop
> which should really be for(auto &x: map), but again, that may have been due
> to a dirty repo.
>
> So while I guess I found a workaround I still would like to know whats
> with the initializer symbols missing in MSVC, can somebody comment?
>
> Thanks!
>
>
> On Thursday, July 9, 2020 at 2:06:21 PM UTC-6, Rodrigo Hernandez wrote:
>>
>> Hello,
>>
>> I am trying to create a VCPKG (https://github.com/microsoft/vcpkg) port
>> of v8,
>> and in doing so I am syncing to tag 8.3.110.13 as suggested here:
>> https://v8.dev/docs/version-numbers
>>
>> Since this is package manager, I want to build against msvc's c++ lib, so
>> I am using use_custom_libcxx=false,
>> however I am seeing linking errors related to undefined symbols on debug
>> builds like:
>>
>> [1797/2086] LINK(DLL) v8.dll v8.dll.lib v8.dll.pdb
>> FAILED: v8.dll v8.dll.lib v8.dll.pdb
>> C:/Code/vcpkg/buildtrees/v8/src/epot_tools-f6c91d5fca/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>> False link.exe /nologo /IMPLIB:./v8.dll.lib /DLL /OUT:./v8.dll
>> /PDB:./v8.dll.pdb @./v8.dll.rsp
>> class-verifiers-tq.obj : error LNK2019: unresolved external symbol
>> "public: class v8::internal::TNode __cdecl
>> v8::internal::TorqueGeneratedExportedMacrosAssembler::IsFastJSArray(class
>> v8::internal::TNode,class
>> v8::internal::TNode)"
>> (?IsFastJSArray@TorqueGeneratedExportedMacrosAssembler@internal@v8
>> @@QEAA?AV?$TNode@UBoolT@internal@v8@@@23@V?$TNode@VObject@internal@v8
>> @@@23@V?$TNode@VContext@internal@v8@@@23@@Z) referenced in function
>> "public: class v8::internal::TNode __cdecl
>> v8::internal::CodeStubAssembler::TaggedToFastJSArray(class
>> v8::internal::TNode,class
>> v8::internal::TNode,class
>> v8::internal::compiler::CodeAssemblerLabel *)"
>> (?TaggedToFastJSArray@CodeStubAssembler@internal@v8
>> @@QEAA?AV?$TNode@VJSArray@internal@v8@@@23@V?$TNode@VContext@internal@v8
>> @@@23@V?$TNode@VObject@internal@v8@@@23@PEAVCodeAssemblerLabel
>> @compiler@23@@Z)
>>
>> There's 75 symbols missing in total, all in class-verifiers-tq.obj, I can
>> post the rest if needed, but hopefully this will give you an idea.
>>
>> On release builds there is only one undefined symbol: void __cdecl
>> v8::internal::FixedArray::set(int,class v8::internal::Smi), which I believe
>> should be in fixed-array-tq-csa.obj,
>> but it is not there. There are 2 overrides right next to its definition
>> in fixed-array-inl.h that do seem to exist in the object file but this one
>> isn't.
>>
>> here is the error output:
>>
>> ninja: Entering directory `out\x64.release'
>> [1/298] LINK mksnapshot.exe mksnapshot.exe.pdb
>> FAILED: mksnapshot.exe mksnapshot.exe.pdb
>> C:/Code/vcpkg/buildtrees/v8/src/epot_tools-f6c91d5fca/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
>> ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64
>> False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb
>> @./mksnapshot.exe.rsp
>> exported-macros-assembler-tq.obj : error LNK2019: unresolved external
>> symbol "public: void __cdecl v8::internal::FixedArray::set(int,class
>> v8::internal::Smi)" (?set@FixedArray@internal@v8@@QEAAXHVSmi@23@@Z)
>> referenced in function "protected: void __cdecl
>> v8::internal::OrderedHashTable> v8::internal::OrderedHashMap,2>::SetNumberOfBuckets(int)"
>> (?SetNumberOfBuckets@?$OrderedHashTable@VOrderedHashMap@internal@v8
>> @@$01@internal@v8@@IEAAXH@Z)
>>
>> .\mksnapshot.exe : fatal error LNK1120: 1 unresolved externals
>>
>> Is there something I can patch to make t

Re: [v8-users] Re: Building v8 shared library on windows

[Ben Ernst]

Following with interest.

Ben


On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst 
wrote:

> Being that this wouldn't be a "high priority" issue, the chance of getting
> it back-ported to older shipped branches is probably low. Sorry for those
> of you stuck on older builds. (Good news is, with v8 shipping every 6
> weeks, you don't have to wait long until 'master' becomes 'legacy' :-)  ).
>
> I actually managed to simplify the changes somewhat by just suppressing a
> harmless MSVC warning that was being treated as an error. I've opened a CL
> against the tip of master at
> https://chromium-review.googlesource.com/c/v8/v8/+/1996157 . With this
> change you should be able to build a release DLL of V8 with MSVC.
>
> There was one linker error in the tests unfortunately I couldn't fix (yet)
> without breaking other platforms, so I had to comment that test out for
> MSVC DLL builds. I'll take another crack at it later. Debug builds of DLLs
> also have further issues on MSVC I haven't tackled yet.
>
>  - Bill
>
>
> On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst wrote:
>>
>> I spent a little more time on this and pushed another commit to my fork
>> of the 8.0 branch (see comparison with upstream 8.0 at
>> https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1
>> ).
>>
>> The tests now compile and pass with MSVC too now. For those following
>> along, this was how I ran the build/test.
>>
>> From the root folder, run the below to generate a x64 release build using
>> MSVC and building DLLs (assuming you're on Windows, obviously)
>>
>> *  python tools\dev\v8gen.py -b x64.release msvc -- is_clang=false
>> is_component_build=true*
>>
>> Run the build, which should complete without error:
>>
>> *  ninja -C out.gn/msvc *
>>
>> If you want to run the tests for good measure:
>>
>> *  python tools/run-tests.py --outdir out.gn/msvc *
>>
>> You should find the resulting v8.dll, along with supporting dlls and .lib
>> files, in the .\out.gn\msvc directory.
>>
>> I haven't tested much beyond running the tests and doing a few ad-hoc D8
>> experiments, and obviously this is unsupported/untested upstream (where the
>> are no bots building/testing/fuzzing this configuration).
>>
>> I'll tidy this up, open a CL, and see if this is something we can get
>> upstreamed, as several folks seem to want this option. Assuming V8/Google
>> doesn't want to run bots for this configuration but is happy to take fixes,
>> is would then be beholden on us (the V8 community) to keep it working.
>> (Personally, it seems to me like the only long-term sustainable solution
>> for cross-compiler support is a C-based API, similar to N-API for Node.js,
>> but I doubt there's much appetite for this currently).
>>
>>  - Bill
>>
>>
>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote:
>>>
>>> Oh, that’s great. Thank you. I will try to apply similar patch locally
>>> to the 7.8.279.23, since I am allowed to use only “stable” versions of V8.
>>>
>>> - Ivan
>>>
>>>
>>>
>>>
>>>
>>> *From: *'Bill Ticehurst' via v8-users
>>> *Sent: *Friday, December 20, 2019 20:02
>>> *To: *v8-users
>>> *Subject: *[v8-users] Re: Building v8 shared library on windows
>>>
>>>
>>>
>>> FWIW: I played around with the last night for a couple hours and got a
>>> release build working using a "component build" and MSVC. It was mostly
>>> moving some inline functions and adding some V8_EXPORT_PRIVATE statements
>>> (which effectively add the "__declspec(dllexport)" statements to expose
>>> functions across DLLs with MSVC). You can see the changes over the current
>>> V8 v8.0 branch at
>>> https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1
>>>
>>>
>>>
>>> This is very rough code, hacking away at one build break at a time until
>>> it worked. I'll need to clean it up with a consistent approach before it
>>> would be ready for a CL. It also only works for the product binaries & D8
>>> so far (i.e. build with "ninja -C out.gn\x64.release d8"), so I need to
>>> fix up the failures when building the test code (which means figuring out
>>> some of the subtlety in
>>> https://github.com/v8/v8/blob/master/src/base/export-template.h ).
>>>
>>>
>>>
>>> Bottom line: It seems fixable without major changes, and should be very
>>> low risk (as the V8_EXPORT_* macros effectively compile to nothing in
>>> static builds - which is what Chromium and Node.js use for release).
>>>
>>>
>>>
>>>  - Bill
>>>
>>> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst
>>> wrote:
>>>
>>> I'm not clear on what is needed to fix this. The bug has been open quite
>>> a while (see https://bugs.chromium.org/p/v8/issues/detail?id=8791).
>>>
>>> On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote:
>>>
>>> Hi Bill, so what needs to be fixed to get DLL build (i.e.
>>> is_component_build=true) built successfully with MSVC compiler?
>>>
>>> I've recently run into the same link

Re: [v8-users] Re: Building v8 shared library on windows

[Ben Ernst]

Bill,
Just wanted to say your work is appreciated. Anything interested parties
can do to help keep msvc builds working? Willing to learn new skills to
contribute, but could use pointing in a good direction.
Ben

On Sun, 22 Dec. 2019, 9:49 am Bill Ticehurst, 
wrote:

> I spent a little more time on this and pushed another commit to my fork of
> the 8.0 branch (see comparison with upstream 8.0 at
> https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1
> ).
>
> The tests now compile and pass with MSVC too now. For those following
> along, this was how I ran the build/test.
>
> From the root folder, run the below to generate a x64 release build using
> MSVC and building DLLs (assuming you're on Windows, obviously)
>
> *  python tools\dev\v8gen.py -b x64.release msvc -- is_clang=false
> is_component_build=true*
>
> Run the build, which should complete without error:
>
> *  ninja -C out.gn/msvc *
>
> If you want to run the tests for good measure:
>
> *  python tools/run-tests.py --outdir out.gn/msvc *
>
> You should find the resulting v8.dll, along with supporting dlls and .lib
> files, in the .\out.gn\msvc directory.
>
> I haven't tested much beyond running the tests and doing a few ad-hoc D8
> experiments, and obviously this is unsupported/untested upstream (where the
> are no bots building/testing/fuzzing this configuration).
>
> I'll tidy this up, open a CL, and see if this is something we can get
> upstreamed, as several folks seem to want this option. Assuming V8/Google
> doesn't want to run bots for this configuration but is happy to take fixes,
> is would then be beholden on us (the V8 community) to keep it working.
> (Personally, it seems to me like the only long-term sustainable solution
> for cross-compiler support is a C-based API, similar to N-API for Node.js,
> but I doubt there's much appetite for this currently).
>
>  - Bill
>
>
> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote:
>>
>> Oh, that’s great. Thank you. I will try to apply similar patch locally to
>> the 7.8.279.23, since I am allowed to use only “stable” versions of V8.
>>
>> - Ivan
>>
>>
>>
>>
>>
>> *From: *'Bill Ticehurst' via v8-users
>> *Sent: *Friday, December 20, 2019 20:02
>> *To: *v8-users
>> *Subject: *[v8-users] Re: Building v8 shared library on windows
>>
>>
>>
>> FWIW: I played around with the last night for a couple hours and got a
>> release build working using a "component build" and MSVC. It was mostly
>> moving some inline functions and adding some V8_EXPORT_PRIVATE statements
>> (which effectively add the "__declspec(dllexport)" statements to expose
>> functions across DLLs with MSVC). You can see the changes over the current
>> V8 v8.0 branch at
>> https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1
>>
>>
>>
>> This is very rough code, hacking away at one build break at a time until
>> it worked. I'll need to clean it up with a consistent approach before it
>> would be ready for a CL. It also only works for the product binaries & D8
>> so far (i.e. build with "ninja -C out.gn\x64.release d8"), so I need to
>> fix up the failures when building the test code (which means figuring out
>> some of the subtlety in
>> https://github.com/v8/v8/blob/master/src/base/export-template.h ).
>>
>>
>>
>> Bottom line: It seems fixable without major changes, and should be very
>> low risk (as the V8_EXPORT_* macros effectively compile to nothing in
>> static builds - which is what Chromium and Node.js use for release).
>>
>>
>>
>>  - Bill
>>
>> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst
>> wrote:
>>
>> I'm not clear on what is needed to fix this. The bug has been open quite
>> a while (see https://bugs.chromium.org/p/v8/issues/detail?id=8791).
>>
>> On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote:
>>
>> Hi Bill, so what needs to be fixed to get DLL build (i.e.
>> is_component_build=true) built successfully with MSVC compiler?
>>
>> I've recently run into the same linking issue with DLL build compiled
>> using clang. And to say truth, it's weird that DLL build works only with
>> clang.
>>
>> p.s. I cannot use prebuilt binaries from nuget and cannot use clang to
>> build my app. Need to use strictly MSVC 2017.
>>
>> - Ivan
>>
>>
>> On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote:
>>
>> To be clear, NuGet is a Microsoft run package manager, but "Microsoft"
>> doesn't offer any pre-built V8 binaries. A user account named "pmed"
>> created/uploaded that package, not a Microsoft account.
>>
>>
>>
>> If you are building V8 in a default manner with Clang as it appears, then
>> you can't link it with a project you're building with the MSVC compiler.
>> Those are two different compilers and C++ doesn't have a cross compiler
>> stable ABI (especially if using "custom_libcxx", which means they are also
>> using a different standard C++ library - V8 the Clang provided

Re: [v8-users] Re: Building v8 shared library on windows

[Ben Ernst]

Thank you for sharing that workaround Ivan, I believe I'm hitting the same 
problem, and your workaround might help me.

On Thursday, 19 December 2019 05:28:41 UTC+10:30, Ivan Pizhenko wrote:
>
> That’s clear, the instruction under the link suggests to build V8 as 
> static library, which we already know to be working. But the point was to 
> build and use V8 as DLL. Meanwhile, I’ve found following workaround: add 2 
> new custom functions to the libplatform, the first one returns normal 
> pointer extracted from return value of the NewDefaultPlatform() and second 
> to delete v8::Platform object (this is to ensure we use both new and delete 
> from libc++), and export these functions from DLL. This way I’ve gotten rid 
> of dependency on the std::unique_ptr version coming from libc++. And based 
> on this experience I’d generally suggest to V8 developers to keep all 
> public V8 APIs w/o any STL stuff for the sake of better integration with 
> different compilers, which with very high probability have different STL 
> implementations than libc++.
>
> - Ivan
>
>  
>
>  
>
> *From: *'Bill Ticehurst' via v8-users 
> *Sent: *Wednesday, December 18, 2019 20:22
> *To: *v8-users 
> *Subject: *[v8-users] Re: Building v8 shared library on windows
>
>  
>
> I believe this is still mostly correct - (some filenames might be out of 
> date, but should give you a general starting point). If you're already 
> building V8 successfully with MSVC, you should be able to skip down to the 
> "Embedding V8 into a custom application" part. 
>
>  
>
>
> https://medium.com/angular-in-depth/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4
>
>  
>
> Disclaimer: As should be obvious by now (and by the above post), this 
> stuff is a moving target (e.g. changing compilers and build outputs over 
> time), non-trivial, and not a first-class supported scenario. The "well 
> trodden" and best supported path is to build your code via a new BUILD.gn 
> target with Clang along with the rest of V8, that way you can ensure your 
> compiler and build settings are all consistent, and the dependencies are 
> largely managed for you. Good luck!
>
>  
>
>  - Bill
>
> On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: 
>
> Ok Bill 
>
> Then I'll build it statically with "is_component_build = false". I don't 
> really need them to be dynamic, I just need them to work.
>
> What file extension should I look for? .lib?
>
> Thank you
>
> -- 
> -- 
> 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/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com
>  
> 
> .
>
>  
>

-- 
-- 
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/9905e52d-3f40-4ab7-9e9f-c1f781f527b6%40googlegroups.com.

[v8-users] Does profiling not work for "component build"?

[Ben Ernst]

The documentation on profiling  states "Make 
sure d8 used for analysis was not built with is_component_build!" Why? Is 
profiling unsupported in the component build? I'm using V8 7.1 component 
build on Ubuntu.
Thanks in advance,
Ben

-- 
-- 
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/5663bf71-2c8c-438f-983b-d8bf385ef6f3%40googlegroups.com.

[v8-users] Re: Alternate for GetCallingContext

[Ben Ernst]

Madan,

I'm using GetCurrentContext() for where I have an isolate but I need a 
context. Have a look at the comments 
. Does that do 
what you need? 

Ben

On Monday, 18 November 2019 22:28:09 UTC+8, madana gopal wrote:
>
> Hi,
>
> We have case, where dynamic functions need to use same context as 
> javascript code that calls it. GetCallingContext() is helping to achieve 
> it, but it is marked as deprecated in code. Please let us know, do we have 
> any alternative api. Or, do we have any way to make dynamic functions use 
> different context, instead of global context.
>
> Thanks.
>
> Regards,
> Madan
>

-- 
-- 
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/ed79d1dc-c853-4ca5-8424-c17f8ffc01d9%40googlegroups.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

Dan, 
I resynced with your landed changes, and reverted 7186b6 as you suggested. 
I encounter the error message below. As ever, I appreciate your ongoing 
correspondence, I am sure it must be a painful process.
Ben

 [exec] FAILED: obj/d8/async-hooks-wrapper.obj
 [exec] 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 
-DENABLE_HANDLE_ZAPPING -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_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS 
-DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DV8_HAVE_TARGET_OS 
-DV8_TARGET_OS_WIN -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED 
-DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS 
-DV8_IMMINENT_DEPRECATION_WARNINGS -DUSING_V8_BASE_SHARED 
-DUSING_V8_PLATFORM_SHARED -I../.. -Igen -I../.. -Igen -I../../include 
-Igen/include -I../../include /Gy /FS /bigobj /utf-8 /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/d8/async-hooks-wrapper.cc 
/Foobj/d8/async-hooks-wrapper.obj /Fd"obj/d8_cc.pdb"
 [exec] C:\fd22cbe1\v8\src/objects/hash-table-inl.h(166): error C2491: 
'v8::internal::HashTable::IsKey': definition of dllimport 
function not allowed

On Saturday, 16 November 2019 00:42:59 UTC+10:30, Dan Elphick wrote:
>
> 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 > 
> 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  
>>> 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  wrote:
>>>>
>>>>> Dan, I have attached th

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

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 
>  #include 
>  
> +#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 
>  
> +#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 
>  #include 
>  
> -#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 > 
> 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 
>>>  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
>

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

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 __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  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>>>>> std::default_delete > __cdecl 
>>>>>> v8::platform::NewDefaultPlatform(int,enum 
>>>>>> v8::pla

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

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  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>>>> std::default_delete > __cdecl 
>>>>> v8::platform::NewDefaultPlatform(int,enum 
>>>>> v8::platform::IdleTaskSupport,enum 
>>>>> v8::platform::InProcessStackDumping,class std::unique_ptr>>>> v8::TracingController,struct std::default_delete>>>> 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 NewDefaultPlatform(
>>>>> int thread_pool_size = 0,
>>>>> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
>>>>> InProcessStackDumping in_process_stack_dumping =
>>>>> InProcessStackDumping::kDisabled,
>>>>> std::unique_ptr 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/6ac7f191-a70b-47ed-8410-c48835e78fdf%40googlegroups.com.

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[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  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>> std::default_delete > __cdecl 
>>> v8::platform::NewDefaultPlatform(int,enum 
>>> v8::platform::IdleTaskSupport,enum 
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct std::default_delete>> 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 NewDefaultPlatform(
>>> int thread_pool_size = 0,
>>> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
>>> InProcessStackDumping in_process_stack_dumping =
>>> InProcessStackDumping::kDisabled,
>>> std::unique_ptr 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/e78c6991-e961-41ba-bfc8-db9882f2ddc6%40googlegroups.com.

Re: [v8-users] How can I resolve or workaround this undefined symbol, building V8 on Windows 10, MSVC++2017?

[Ben Ernst]

Thank you Jakob for your advice.
For the record, for anyone stumbling across this thread, I changed 
ingredient (1), and built just targets "v8", "v8_base" and "v8_platform" by 
passing those arguments to Ninja.
Ben


On Thursday, 31 October 2019 00:39:15 UTC+10:30, Jakob Kummerow wrote:
>
> If I had to guess: unibrow::ToUppercase::Convert in src/strings/unicode.h 
> needs a V8_EXPORT_PRIVATE annotation in order to support the specific 
> combination of building (1) cctests (2) on Windows (3) with 
> is_component_build = true and (4) with v8_enable_i18n_support = false.
>
> If that theory is correct, then for a quick workaround, you can change any 
> of those four ingredients to the situation. (E.g. if all you need is a DLL 
> to link your embedding application against, simply don't build cctests.exe.)
>
>
> On Wed, Oct 30, 2019 at 2:09 PM Ben Ernst > 
> wrote:
>
>> I am building V8 7.8 (Windows 10, MSVC++ 2017) . My arguments to "GN" 
>> are as follows:
>>
>> treat_warnings_as_errors=false
>> is_component_build=true
>> v8_enable_i18n_support=false
>> v8_use_snapshot=true
>>
>> I invoke ninja as follows. 
>>
>> ninja -C out.gn/x64.release 
>>
>> I encounter the below error toward the end of the build. An undefined 
>> symbol referring to "unibrow". Any idea how I might resolve or work around 
>> this error? Thank you in advance for any advice.
>>
>>  [exec] [1204/1220] CXX 
>> obj/test/cctest/cctest_sources/test-run-wasm-atomics.obj
>>  [exec] [1205/1220] CXX 
>> obj/test/cctest/cctest_sources/test-orderedhashtable.obj
>>  [exec] [1206/1220] CXX obj/test/cctest/cctest_sources/test-roots.obj
>>  [exec] [1207/1220] CXX 
>> obj/tools/debug_helper/v8_debug_helper/class-debug-readers-tq.obj
>>  [exec] [1208/1220] CXX obj/test/cctest/cctest_sources/test-types.obj
>>  [exec] [1209/1220] CXX 
>> obj/tools/debug_helper/v8_debug_helper/get-object-properties.obj
>>  [exec] [1210/1220] LINK(DLL) v8_debug_helper.dll 
>> v8_debug_helper.dll.lib v8_debug_helper.dll.pdb
>>  [exec] [1211/1220] STAMP obj/test/cctest/cctest_sources.stamp
>>  [exec] [1212/1220] LINK cctest.exe cctest.exe.pdb
>>  [exec] FAILED: cctest.exe cctest.exe.pdb
>>  [exec] ninja -t msvc -e environment.x64 -- 
>> ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo 
>> /OUT:./cctest.exe /PDB:./cctest.exe.pdb @./cctest.exe.rsp
>>  [exec] lld-link: error: undefined symbol: public: static int __cdecl 
>> unibrow::ToUppercase::Convert(unsigned int, unsigned int, unsigned int *, 
>> bool *)
>>  [exec] >>> referenced by .\..\..\test\cctest\test-regexp.cc:1333
>>  [exec] >>>  
>>  obj/test/cctest/cctest_sources/test-regexp.obj:(void __cdecl 
>> v8::internal::test_regexp::TestLatinCanonicalize(void))
>>  [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1642
>>  [exec] >>>  
>>  obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
>> v8::internal::test_strings::TestLatin1IgnoreCase(void))
>>  [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1658
>>  [exec] >>>  
>>  obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
>> v8::internal::test_strings::TestLatin1IgnoreCase(void))
>>  [exec]
>>  [exec] lld-link: error: undefined symbol: public: static int __cdecl 
>> unibrow::ToLowercase::Convert(unsigned int, unsigned int, unsigned int *, 
>> bool *)
>>  [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1641
>>  [exec] >>>  
>>  obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
>> v8::internal::test_strings::TestLatin1IgnoreCase(void))
>>  [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1655
>>  [exec] >>>  
>>  obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
>> v8::internal::test_strings::TestLatin1IgnoreCase(void))
>>  [exec] [1213/1220] LINK wasm_api_tests.exe wasm_api_tests.exe.pdb
>>  [exec] [1214/1220] LINK unittests.exe unittests.exe.pdb
>>  [exec] ninja: build stopped: subcommand failed.
>>
>> -- 
>> -- 
>> 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

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

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 > 
> 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> std::default_delete > __cdecl 
>> v8::platform::NewDefaultPlatform(int,enum 
>> v8::platform::IdleTaskSupport,enum 
>> v8::platform::InProcessStackDumping,class std::unique_ptr> v8::TracingController,struct std::default_delete> 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 NewDefaultPlatform(
>> int thread_pool_size = 0,
>> IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
>> InProcessStackDumping in_process_stack_dumping =
>> InProcessStackDumping::kDisabled,
>> std::unique_ptr 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/3c25d09f-f679-4a08-bf47-e2075aa39866%40googlegroups.com.

Re: [v8-users] Is "monolithic" build of v8 for static linking incompatible with "v8_use_snapshot=true"?

[Ben Ernst]

Jakob, your tip has helped, thank you. That flag seemed to do the trick.
Ben

-- 
-- 
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/6be8b435-216d-47a9-a28c-1d8fc1227127%40googlegroups.com.

Re: [v8-users] What do these unresolved external symbols mean when building against V8 7.8 "monolithic"?

[Ben Ernst]

Simon,
Thank you, I'm not completely out of the weeds yet, but most of my 
libraries are now building with your tip "use_custom_libcxx=false".
Cheers,
Ben

On Wednesday, 30 October 2019 23:35:50 UTC+10:30, Ben Ernst wrote:
>
> Simon
> Thank you, I will try that solution today.
> Ben
>
> On Wednesday, 30 October 2019 18:40:42 UTC+10:30, Simon Zünd wrote:
>>
>> Best guess, you linked the V8 monolith static library with the libstdc++ 
>> thats pulled in by "gclient sync". The project itself is linked against the 
>> standard library of Visual Studio.
>>
>> There is a GN option for this, try "use_custom_libcxx = false", which 
>> will build V8 with the system C++ standard library.
>>
>> On Wed, Oct 30, 2019 at 8:02 AM Ben Ernst  wrote:
>>
>>> My platform is Windows 10, Visual C++ 2017.
>>>
>>> I build a "monolithic" V8, and try to link against it. I am buried under 
>>> linker errors.
>>>
>>> Just a taste below, the rest are attached. Any idea what I might be 
>>> doing wrong? I don't remotely what I have supposedly done wrong.
>>>
>>>
>>>
>>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol "class 
>>> std::unique_ptr>> v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum 
>>> v8::platform::IdleTaskSupport,enum 
>>> v8::platform::InProcessStackDumping,class std::unique_ptr>> v8::TracingController,struct std::default_delete>> v8::TracingController> >)" 
>>> (?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)
>>> 1>node_inspector_agent.obj : error LNK2019: unresolved external symbol 
>>> "public: static class std::unique_ptr>> v8_inspector::StringBuffer,struct std::default_delete>> v8_inspector::StringBuffer> > __cdecl 
>>> v8_inspector::StringBuffer::create(class v8_inspector::StringView const &)" 
>>> (?create@StringBuffer@v8_inspector@@SA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@AEBVStringView@2@@Z)
>>>  
>>> referenced in function "class std::unique_ptr>> v8_inspector::StringBuffer,struct std::default_delete>> v8_inspector::StringBuffer> > __cdecl inspector::`anonymous 
>>> namespace'::ToProtocolString(class v8::Isolate *,class v8::Local>> v8::Value>)" 
>>> (?ToProtocolString@?A0xd3023fdb@inspector@@YA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@PEAVIsolate@v8@@V?$Local@VValue@v8@@@6@@Z)
>>> 1>node_inspector_io.obj : error LNK2001: unresolved external symbol 
>>> "public: static class std::unique_ptr>> v8_inspector::StringBuffer,struct std::default_delete>> v8_inspector::StringBuffer> > __cdecl 
>>> v8_inspector::StringBuffer::create(class v8_inspector::StringView const &)" 
>>> (?create@StringBuffer@v8_inspector@@SA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@AEBVStringView@2@@Z)
>>> 1>node_inspector_agent.obj : error LNK2019: unresolved external symbol 
>>> "public: static class std::unique_ptr>> v8_inspector::V8Inspector,struct std::default_delete>> v8_inspector::V8Inspector> > __cdecl 
>>> v8_inspector::V8Inspector::create(class v8::Isolate *,class 
>>> v8_inspector::V8InspectorClient *)" 
>>> (?create@V8Inspector@v8_inspector@@SA?AV?$unique_ptr@VV8Inspector@v8_inspector@@U?$default_delete@VV8Inspector@v8_inspector@@@std@@@std@@PEAVIsolate@v8@@PEAVV8InspectorClient@2@@Z)
>>>  
>>> referenced in function "public: __cdecl 
>>> inspector::CBInspectorClient::CBInspectorClient(class v8::Isolate *,class 
>>> v8::Platform *)" 
>>> (??0CBInspectorClient@inspector@@QEAA@PEAVIsolate@v8@@PEAVPlatform@3@@Z)
>>> 1>v8_monolith.lib(bytecode-array-random-iterator.obj) : error LNK2001: 
>>> unresolved external symbol "protected: void __cdecl 
>>> std::__1::__vector_base_common<1>::__throw_length_error(void)const " 
>>> (?__throw_length_error@?$__vector_base_common@$00@__1@std@@IEBAXXZ)
>>> 1>v8_monolith.lib(liftoff-assembler.obj)

[v8-users] Is "is_component_build" expected to work at all in v8 7.8?

[Ben Ernst]

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 > __cdecl 
v8::platform::NewDefaultPlatform(int,enum 
v8::platform::IdleTaskSupport,enum 
v8::platform::InProcessStackDumping,class std::unique_ptr >)" 
(__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 NewDefaultPlatform(
int thread_pool_size = 0,
IdleTaskSupport idle_task_support = IdleTaskSupport::kDisabled,
InProcessStackDumping in_process_stack_dumping =
InProcessStackDumping::kDisabled,
std::unique_ptr 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/34747261-186a-43b3-8383-9d85857b2e66%40googlegroups.com.

Re: [v8-users] NewDefaultPlatform() unresolved external symbol

[Ben Ernst]

Joe, I have the same problem. Static build, dynamic build, debug build, 
release build, I get unresolved external symbols with every build.

On Monday, 30 September 2019 19:24:43 UTC+9:30, Joe Smack wrote:
>
> That just gives me other errors. I've looked at the 
> https://bugs.chromium.org/p/v8/issues/list and I really just think the 
> debug build is broken right now for win 10/MSVC.
>
> On Wednesday, September 25, 2019 at 5:18:07 AM UTC-7, Simon Zünd wrote:
>>
>> Could be related to the GN argument `use_custom_libcxx`. Try setting it 
>> to true. My suspicion is, that the linked std::unique_ptr from your 
>> executable doesn't match the std::unique_ptr from the V8 library.
>>
>> On Wed, Sep 25, 2019 at 1:26 PM Joe Smack  wrote:
>>
>>> I followed the instructions. I've tried several different setups and it 
>>> just seems to me that V8's debug setup is screwed up. (Release build is 
>>> fine.)
>>>
>>> On Monday, September 23, 2019 at 1:41:12 AM UTC-7, Jakob Kummerow wrote:

 Does it help if you follow the instructions ? 
 Specifically the part where it suggests to build v8_monolith and then link 
 against exactly that one library.

 Does #pragma comment(lib, "v8_libplatform.dll.lib") mean that you're 
 actually linking against v8_libplatform?


 On Sun, Sep 22, 2019 at 2:33 PM Joe Smack  wrote:

> Can anyone please help me resolve this? I can't get rid of this error 
> :\
>
>
> I'm using version 7.7.299.11 of v8 and latest version of msvc.
>
> args.gn file
> is_component_build = false
> is_debug = false
> symbol_level = 1
> target_cpu = "x64"
> use_goma = false
>
>
> My code:
> #include 
> #include 
> #include 
> #include 
>
> #include 
> #include 
>
> #pragma comment(lib, "v8.dll.lib")
> #pragma comment(lib, "v8_libbase.dll.lib")
> #pragma comment(lib, "v8_libplatform.dll.lib")
> #pragma comment(lib, "icui18n.dll.lib")
> #pragma comment(lib, "icuuc.dll.lib")
> #pragma comment(lib, "wee8.lib")
>
>
> int main()
> {
> if (v8::V8::InitializeICUDefaultLocation("v8 hello world.exe", 
> "icudtl.dat") == false)
> return 0;
>
> v8::V8::InitializeExternalStartupData("natives_blob.bin", 
> "snapshot_blob.bin");
>
>
> std::unique_ptr platform = 
> v8::platform::NewDefaultPlatform();
>
> return 0;
> }
>
> My error:
> Severity Code Description Project File Line Suppression State
> Error LNK2019 unresolved external symbol "class std::unique_ptr v8::Platform,struct std::default_delete > 
> __cdecl v8::platform::NewDefaultPlatform(int,enum 
> v8::platform::IdleTaskSupport,enum 
> v8::platform::InProcessStackDumping,class 
> std::unique_ptr std::default_delete >)" 
>
> (?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 main v8 test app 
> C:\Users\Documents\Visual Studio 2019\projects\v8 test app\v8 test 
> app\v8 test app.obj 1 
>
> -- 
>
 -- 
>>> -- 
>>> 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/36252d92-bdaa-4742-bc71-07de0ede30ec%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
-- 
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/1090185e-965b-47b0-b27b-6e9f42b11e5f%40googlegroups.com.

[v8-users] How can I resolve or workaround this undefined symbol, building V8 on Windows 10, MSVC++2017?

[Ben Ernst]

I am building V8 7.8 (Windows 10, MSVC++ 2017) . My arguments to "GN" are 
as follows:

treat_warnings_as_errors=false
is_component_build=true
v8_enable_i18n_support=false
v8_use_snapshot=true

I invoke ninja as follows. 

ninja -C out.gn/x64.release 

I encounter the below error toward the end of the build. An undefined 
symbol referring to "unibrow". Any idea how I might resolve or work around 
this error? Thank you in advance for any advice.

 [exec] [1204/1220] CXX 
obj/test/cctest/cctest_sources/test-run-wasm-atomics.obj
 [exec] [1205/1220] CXX 
obj/test/cctest/cctest_sources/test-orderedhashtable.obj
 [exec] [1206/1220] CXX obj/test/cctest/cctest_sources/test-roots.obj
 [exec] [1207/1220] CXX 
obj/tools/debug_helper/v8_debug_helper/class-debug-readers-tq.obj
 [exec] [1208/1220] CXX obj/test/cctest/cctest_sources/test-types.obj
 [exec] [1209/1220] CXX 
obj/tools/debug_helper/v8_debug_helper/get-object-properties.obj
 [exec] [1210/1220] LINK(DLL) v8_debug_helper.dll 
v8_debug_helper.dll.lib v8_debug_helper.dll.pdb
 [exec] [1211/1220] STAMP obj/test/cctest/cctest_sources.stamp
 [exec] [1212/1220] LINK cctest.exe cctest.exe.pdb
 [exec] FAILED: cctest.exe cctest.exe.pdb
 [exec] ninja -t msvc -e environment.x64 -- 
../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo 
/OUT:./cctest.exe /PDB:./cctest.exe.pdb @./cctest.exe.rsp
 [exec] lld-link: error: undefined symbol: public: static int __cdecl 
unibrow::ToUppercase::Convert(unsigned int, unsigned int, unsigned int *, 
bool *)
 [exec] >>> referenced by .\..\..\test\cctest\test-regexp.cc:1333
 [exec] >>>  
 obj/test/cctest/cctest_sources/test-regexp.obj:(void __cdecl 
v8::internal::test_regexp::TestLatinCanonicalize(void))
 [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1642
 [exec] >>>  
 obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
v8::internal::test_strings::TestLatin1IgnoreCase(void))
 [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1658
 [exec] >>>  
 obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
v8::internal::test_strings::TestLatin1IgnoreCase(void))
 [exec]
 [exec] lld-link: error: undefined symbol: public: static int __cdecl 
unibrow::ToLowercase::Convert(unsigned int, unsigned int, unsigned int *, 
bool *)
 [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1641
 [exec] >>>  
 obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
v8::internal::test_strings::TestLatin1IgnoreCase(void))
 [exec] >>> referenced by .\..\..\test\cctest\test-strings.cc:1655
 [exec] >>>  
 obj/test/cctest/cctest_sources/test-strings.obj:(void __cdecl 
v8::internal::test_strings::TestLatin1IgnoreCase(void))
 [exec] [1213/1220] LINK wasm_api_tests.exe wasm_api_tests.exe.pdb
 [exec] [1214/1220] LINK unittests.exe unittests.exe.pdb
 [exec] ninja: build stopped: subcommand failed.

-- 
-- 
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/f7c1fe8f-f3a7-4f93-9764-465068250568%40googlegroups.com.

Re: [v8-users] What do these unresolved external symbols mean when building against V8 7.8 "monolithic"?

[Ben Ernst]

Simon
Thank you, I will try that solution today.
Ben

On Wednesday, 30 October 2019 18:40:42 UTC+10:30, Simon Zünd wrote:
>
> Best guess, you linked the V8 monolith static library with the libstdc++ 
> thats pulled in by "gclient sync". The project itself is linked against the 
> standard library of Visual Studio.
>
> There is a GN option for this, try "use_custom_libcxx = false", which will 
> build V8 with the system C++ standard library.
>
> On Wed, Oct 30, 2019 at 8:02 AM Ben Ernst > 
> wrote:
>
>> My platform is Windows 10, Visual C++ 2017.
>>
>> I build a "monolithic" V8, and try to link against it. I am buried under 
>> linker errors.
>>
>> Just a taste below, the rest are attached. Any idea what I might be doing 
>> wrong? I don't remotely what I have supposedly done wrong.
>>
>>
>>
>> 1>ezv8_platform.obj : error LNK2019: unresolved external symbol "class 
>> std::unique_ptr> v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum 
>> v8::platform::IdleTaskSupport,enum 
>> v8::platform::InProcessStackDumping,class std::unique_ptr> v8::TracingController,struct std::default_delete> v8::TracingController> >)" 
>> (?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)
>> 1>node_inspector_agent.obj : error LNK2019: unresolved external symbol 
>> "public: static class std::unique_ptr> v8_inspector::StringBuffer,struct std::default_delete> v8_inspector::StringBuffer> > __cdecl 
>> v8_inspector::StringBuffer::create(class v8_inspector::StringView const &)" 
>> (?create@StringBuffer@v8_inspector@@SA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@AEBVStringView@2@@Z)
>>  
>> referenced in function "class std::unique_ptr> v8_inspector::StringBuffer,struct std::default_delete> v8_inspector::StringBuffer> > __cdecl inspector::`anonymous 
>> namespace'::ToProtocolString(class v8::Isolate *,class v8::Local> v8::Value>)" 
>> (?ToProtocolString@?A0xd3023fdb@inspector@@YA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@PEAVIsolate@v8@@V?$Local@VValue@v8@@@6@@Z)
>> 1>node_inspector_io.obj : error LNK2001: unresolved external symbol 
>> "public: static class std::unique_ptr> v8_inspector::StringBuffer,struct std::default_delete> v8_inspector::StringBuffer> > __cdecl 
>> v8_inspector::StringBuffer::create(class v8_inspector::StringView const &)" 
>> (?create@StringBuffer@v8_inspector@@SA?AV?$unique_ptr@VStringBuffer@v8_inspector@@U?$default_delete@VStringBuffer@v8_inspector@@@std@@@std@@AEBVStringView@2@@Z)
>> 1>node_inspector_agent.obj : error LNK2019: unresolved external symbol 
>> "public: static class std::unique_ptr> v8_inspector::V8Inspector,struct std::default_delete> v8_inspector::V8Inspector> > __cdecl 
>> v8_inspector::V8Inspector::create(class v8::Isolate *,class 
>> v8_inspector::V8InspectorClient *)" 
>> (?create@V8Inspector@v8_inspector@@SA?AV?$unique_ptr@VV8Inspector@v8_inspector@@U?$default_delete@VV8Inspector@v8_inspector@@@std@@@std@@PEAVIsolate@v8@@PEAVV8InspectorClient@2@@Z)
>>  
>> referenced in function "public: __cdecl 
>> inspector::CBInspectorClient::CBInspectorClient(class v8::Isolate *,class 
>> v8::Platform *)" 
>> (??0CBInspectorClient@inspector@@QEAA@PEAVIsolate@v8@@PEAVPlatform@3@@Z)
>> 1>v8_monolith.lib(bytecode-array-random-iterator.obj) : error LNK2001: 
>> unresolved external symbol "protected: void __cdecl 
>> std::__1::__vector_base_common<1>::__throw_length_error(void)const " 
>> (?__throw_length_error@?$__vector_base_common@$00@__1@std@@IEBAXXZ)
>> 1>v8_monolith.lib(liftoff-assembler.obj) : error LNK2001: unresolved 
>> external symbol "protected: void __cdecl 
>> std::__1::__vector_base_common<1>::__throw_length_error(void)const " 
>> (?__throw_length_error@?$__vector_base_common@$00@__1@std@@IEBAXXZ)
>> 1>v8_monolith.lib(constant-array-builder.obj) : error LNK2001: unresolved 
>> external symbol "protected: void __cdecl 
>> std::__1::__vector_base_common<1>::__throw_length_error(void)const " 
>> (?__throw_length_error@?$__vector_base_common

Re: [v8-users] Is "monolithic" build of v8 for static linking incompatible with "v8_use_snapshot=true"?

[Ben Ernst]

Thank you Jakob, it built successfully with your change, now I just have to
link to it.

On Tue, 29 Oct 2019 at 16:57, Jakob Gruber  wrote:

> Set
>
> v8_use_external_startup_data = false
>
> to compile the snapshot into the binary. I don't think there's any reason
> external snapshots would not work in monolithic builds. The assert is
> likely guarding the fact that the build produces exactly one single file.
>
> On Tue, Oct 29, 2019 at 7:07 AM Ben Ernst  wrote:
>
>> Following some frustrations with dynamic linking to V8, I thought I'd try
>> the static linked build.
>>
>> My platform is VS2017, Windows 10.
>>
>> My arguments to "gn" (via "v8gen") are as follows:
>>
>> treat_warnings_as_errors=false
>> is_component_build=false
>> v8_enable_i18n_support=false
>> v8_use_snapshot=true
>> v8_monolithic=true
>>
>> When I try to build V8, I get this error:
>>
>>  [exec]
>> **
>>  [exec] ** Visual Studio 2017 Developer Command Prompt v15.9.11
>>  [exec] ** Copyright (c) 2017 Microsoft Corporation
>>  [exec]
>> **
>>  [exec] [vcvarsall.bat] Environment initialized for: 'x64'
>>  [exec] ninja: Entering directory `out.gn/x64.release'
>>  [exec] [1/1] Regenerating ninja files
>>  [exec] FAILED: build.ninja
>>  [exec] ../../buildtools/win/gn.exe --root=../.. -q --check gen .
>>  [exec] ERROR at //BUILD.gn:3779:3: Assertion failed.
>>  [exec]   assert(!v8_use_external_startup_data)
>>  [exec]   ^-
>>  [exec] ninja: error: rebuilding 'build.ninja': subcommand failed
>>
>> Is "v8_monolith" incompatible with "v8_use_snapshot"? How does one get
>> around this problem?
>>
>> --
>> --
>> 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/1ff68a3b-07c3-43f6-aaed-56a8001a7fe8%40googlegroups.com
>> <https://groups.google.com/d/msgid/v8-users/1ff68a3b-07c3-43f6-aaed-56a8001a7fe8%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/CAH3p7oPKpFHd7xBtmuoS6Pj_jhcXSVTBTCPMO-qnDhAsiE0trQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/v8-users/CAH3p7oPKpFHd7xBtmuoS6Pj_jhcXSVTBTCPMO-qnDhAsiE0trQ%40mail.gmail.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/CABexdQ4%2Biaf%2BgGX6F_paG6z%3DQ-AU588LM3yj-7RQS_dc%2BeOsJg%40mail.gmail.com.

[v8-users] Is "monolithic" build of v8 for static linking incompatible with "v8_use_snapshot=true"?

[Ben Ernst]

Following some frustrations with dynamic linking to V8, I thought I'd try 
the static linked build.

My platform is VS2017, Windows 10.

My arguments to "gn" (via "v8gen") are as follows:

treat_warnings_as_errors=false
is_component_build=false
v8_enable_i18n_support=false
v8_use_snapshot=true
v8_monolithic=true

When I try to build V8, I get this error:

 [exec] 
**
 [exec] ** Visual Studio 2017 Developer Command Prompt v15.9.11
 [exec] ** Copyright (c) 2017 Microsoft Corporation
 [exec] 
**
 [exec] [vcvarsall.bat] Environment initialized for: 'x64'
 [exec] ninja: Entering directory `out.gn/x64.release'
 [exec] [1/1] Regenerating ninja files
 [exec] FAILED: build.ninja
 [exec] ../../buildtools/win/gn.exe --root=../.. -q --check gen .
 [exec] ERROR at //BUILD.gn:3779:3: Assertion failed.
 [exec]   assert(!v8_use_external_startup_data)
 [exec]   ^-
 [exec] ninja: error: rebuilding 'build.ninja': subcommand failed

Is "v8_monolith" incompatible with "v8_use_snapshot"? How does one get 
around this problem?

-- 
-- 
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/1ff68a3b-07c3-43f6-aaed-56a8001a7fe8%40googlegroups.com.

[v8-users] Linker errors upgrading from V8 7.1 to 7.8

[Ben Ernst]

Hello.

I have been trying to upgrade my code from V8 v7.1 to 7.8. I'm using V8 
version 7.8.279, which I'm picking from git branch 7.8.279 (please tell me 
if this is the wrong way to do it!).

I'm using v8gen.py to perform the build, and passing these arguments (via 
v8gen) to "gn"

treat_warnings_as_errors=false
is_component_build=true
v8_enable_i18n_support=false
v8_use_snapshot=true

I invoke ninja as follows. I cite specific targets here, because one of the 
testing-related targets fails to build on my system.

ninja -C out.gn/x64.release v8 v8_libbase v8_libplatform

>From this build, I get '.lib' and '.dll' files as expected, and I dynamic 
link my own code to V8 using the lib files: "v8.dll.lib" 
"v8_libbase.dll.lib" "v8_libplatform.dll.lib".

I've updated all of my code to conform with the API changes between V8 7.1 
and V8 7.8.

During linking, I get the following errors below. I note that this all 
works fine on V8 7.1, but I tried 7.6, and 7.7 with very similar results.

I would appreciate any advice. Thanks a bunch!

Ben

1>-- Build started: Project: my-library, Configuration: Release x64 
--
1>   Creating library C:\my-local-path\Release\x64\my-library.lib and 
object C:\my-local-path\Release\x64\my-library.exp
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl 
v8::ResourceConstraints::ResourceConstraints(void)" 
(__imp_??0ResourceConstraints@v8@@QEAA@XZ) referenced in function "public: 
__cdecl my-library::ezIsolate::Impl::Impl(void)" 
(??0Impl@ezIsolate@my-library@@QEAA@XZ)
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: unsigned __int64 __cdecl 
v8::HeapStatistics::total_heap_size(void)" 
(__imp_?total_heap_size@HeapStatistics@v8@@QEAA_KXZ) referenced in function 
"public: void __cdecl 
::operator()(struct 
appsvcs::async::CancellationToken const &)const " 
(??R@@QEBAXAEBUCancellationToken@async@appsvcs@@@Z)
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: unsigned __int64 __cdecl 
v8::HeapStatistics::total_physical_size(void)" 
(__imp_?total_physical_size@HeapStatistics@v8@@QEAA_KXZ) referenced in 
function "public: void __cdecl 
::operator()(struct 
appsvcs::async::CancellationToken const &)const " 
(??R@@QEBAXAEBUCancellationToken@async@appsvcs@@@Z)
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: unsigned __int64 __cdecl 
v8::HeapStatistics::used_heap_size(void)" 
(__imp_?used_heap_size@HeapStatistics@v8@@QEAA_KXZ) referenced in function 
"public: void __cdecl 
::operator()(struct 
appsvcs::async::CancellationToken const &)const " 
(??R@@QEBAXAEBUCancellationToken@async@appsvcs@@@Z)
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::Scope(class 
v8::Isolate *)" (__imp_??0Scope@Isolate@v8@@QEAA@PEAV12@@Z) referenced in 
function "public: void __cdecl my-library::ezIsolate::AttatchDebugger(class 
my-library::Ezv8 *)" 
(?AttatchDebugger@ezIsolate@my-library@@QEAAXPEAVEzv8@2@@Z)
1>my-library_my-library.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::Scope(class 
v8::Isolate *)" (__imp_??0Scope@Isolate@v8@@QEAA@PEAV12@@Z)
1>my-library_ffiwrapper.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::Scope(class 
v8::Isolate *)" (__imp_??0Scope@Isolate@v8@@QEAA@PEAV12@@Z)
1>my-library_utility.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::Scope(class 
v8::Isolate *)" (__imp_??0Scope@Isolate@v8@@QEAA@PEAV12@@Z)
1>my-library_ezisolate.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::~Scope(void)" 
(__imp_??1Scope@Isolate@v8@@QEAA@XZ) referenced in function "public: void 
__cdecl my-library::ezIsolate::AttatchDebugger(class my-library::Ezv8 *)" 
(?AttatchDebugger@ezIsolate@my-library@@QEAAXPEAVEzv8@2@@Z)
1>my-library_my-library.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::~Scope(void)" 
(__imp_??1Scope@Isolate@v8@@QEAA@XZ)
1>my-library_ffiwrapper.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::~Scope(void)" 
(__imp_??1Scope@Isolate@v8@@QEAA@XZ)
1>my-library_utility.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) public: __cdecl v8::Isolate::Scope::~Scope(void)" 
(__imp_??1Scope@Isolate@v8@@QEAA@XZ)
1>my-library_my-library.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl 
v8::EscapableHandleScope::~EscapableHandleScope(void)" 
(__imp_??1EscapableHandleScope@v8@@QEAA@XZ) referenced in function "int 
`public: __cdecl my-library::Ezv8::Impl::Impl(class v8::Isolate 
*,bool)'::`1'::