Errors Building v8 8.3.110.13 for Windows with is_component_build=true target_cpu="x64" is_clang=false use_custom_libcxx=false

[Rodrigo Hernandez]

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<struct v8::internal::BoolT> __cdecl v8::internal::TorqueGeneratedExportedMacrosAssembler::IsFastJSArray(class v8::internal::TNode<class v8::internal::Object>,class v8::internal::TNode<class v8::internal::Context>)" (?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<class v8::internal::JSArray> __cdecl v8::internal::CodeStubAssembler::TaggedToFastJSArray(class v8::internal::TNode<class v8::internal::Context>,class v8::internal::TNode<class v8::internal::Object>,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<class 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!

[Rodrigo Hernandez]

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!

[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

--
--
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/b214e6f1-722b-4c8d-b466-9b6900b437c7o%40googlegroups.com.

[Rodrigo Hernandez]

Thanks Ben, I will try that. 

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CABexdQ5Y4bj8wNUt7OPwAJg1O0sg%3DkKtn%3DD_4WZS_Sus6Rr5mw%40mail.gmail.com.

[Bill Ticehurst]

If you search for my last name on this or the v8-dev forum, you'll find a lot of attempts at fixing this, and ultimately giving up. (e.g. https://groups.google.com/forum/#!searchin/v8-users/ticehurst|sort:date/v8-users/mmwWxpb64_I/HtL-SI9wBgAJ might be the most relevant). Basically MSVC is not a fully supported compiler. static releases builds are tested (e.g. that's how Node.js builds), but everything else is untested and breaks pretty quickly even if you get a fix in.

- Bill

On Monday, July 13, 2020 at 7:41:39 AM UTC-7, Rodrigo Hernandez wrote:

Thanks Ben, I will try that. 

On Mon, Jul 13, 2020, 4:54 AM Ben Ernst <boi...@gmail.com> wrote:

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

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/b214e6f1-722b-4c8d-b466-9b6900b437c7o%40googlegroups.com.

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

[Rodrigo Hernandez]

Thanks Bill, I'll take a look at your fixes.

Part of why I want to have a working vcpkg port is to have more developers use it and contribute to it, so hopefully further breakage is at least not as bad.

[Rodrigo Hernandez]

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<int64_t> 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.

[Rodrigo Hernandez]

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.

[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

--

--
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/20e44a86-a777-4291-a663-ed8c52fd7d35o%40googlegroups.com.

[Rodrigo Hernandez]

Hi Ben,

Do you mean what am I going that merits all this trouble? 😁

I work on my game engine on my spare time, and I am planning on using V8 as the underlying JavaScript engine,

However my immediate need is to use it to power the engine UI, which is a separate project.

My idea is to create a small SVG Browser Agent that can be put as an OpenGL or Vulkan Overlay in the game engine,

using regular JS to drive animations and events in the SVG page.

I tried using Electron, but it turned out that you don't embed Electron, Electron embeds you,

and in the end I had to hack too many things to get it barely working on Windows and Linux was a no go.

So, I figured I might as well give pure v8 a new try (I used to have cmake scripts to build v8 back when it used scons).

I noticed there was no v8 package on MSYS2, despite there being one some years ago, so I started working on that,

then tried to install v8 on VCPKG and it just wasn't there despite being requested since long ago (https://github.com/microsoft/vcpkg/issues/372),

and now here I am 😆.

TL;DR:  here's the links for my projects:

https://github.com/AeonGames/AeonEngine

https://github.com/AeonGames/AeonGUI

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Rodrigo Hernandez]

Quick Update:

I am working on linking against the zlib and icu vcpkg ports instead of the embedded ones, in the meantime I am attaching the patches for 8.3.110.13.

Once you have synched to 8.3.110.13, apply the v8.patch in the v8 directory and the build.patch in the build directory:

git apply v8.patch

git apply build.patch

Then configure with gn:

gn gen out/x64.release.msvc --args="is_debug=false is_component_build=true target_cpu=\"x64\" is_clang=false use_custom_libcxx=false v8_enable_verify_heap=false"

gn gen out/x64.debug.msvc --args="is_debug=true is_component_build=true target_cpu=\"x64\" is_clang=false use_custom_libcxx=false v8_enable_verify_heap=false"

and build with ninja:

ninja -C out/x64.release.msvc

ninja -C out/x64.debug.msvc

These changes are small, so it would be nice to have them in master "hint-hint", 

I may be able to create a CL later on, but if someone can help with that, it would be great.

Cheers!

On Thursday, July 9, 2020 at 2:06:21 PM UTC-6, Rodrigo Hernandez wrote:

[Rodrigo Hernandez]

Quick Update:

I have successfully built the vcpkg package linking ICU and zlib vcpkg ports,

I still need to work on the final details such as cmake config file so cmake based projects can find the libraries and headers

as well as check that static builds fine too. Then I need to make sure it works on Linux which was something vcpkg bots checked for last time I submitted a port.

That last one is probably the one that's going to take more time.

Cheers!

On Thursday, July 9, 2020 at 2:06:21 PM UTC-6, Rodrigo Hernandez wrote:

[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:

[kosit la-orngsri]

สวัสดี

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

[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<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >)" (?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

[Rodrigo Hernandez]

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.

[Rodrigo Hernandez]

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 😁

[Ben Ernst]

Thanks, that'll be helpful.