Intention to contribute, to fix MSVC "component build", broken from v7.2 onwards.

[Ben Ernst]

Hey all,

I intend to try my hand at contributing here, so I'm introducing myself in accordance with the directions on the "contributing to V8" page. The MSVC "component build" of V8 has been broken since v7.2. I will do my best to get it working again. I thoroughly appreciate any guidance along the way. Dan Elphick has been a huge help already. This is my first time contributing to a big project, I will do my best to work in accordance with the documented processes. If you're wondering why the clang build is not working for me, here's my linker errors. Speaking from a position of a relative newbie, it looks like clang doesn't think it needs to export certain symbols, but MSVC expects them to be exported.

I do have a question someone might be able to help me with. If I manage to get this build working, would it be possible/practical/desirable to add this configuration to the CI build system long term? Dan did mention it's "not officially supported".

Any way, wish me luck.

Cheers,

Ben

[Ben Ernst]

I have a quick question someone might be able to help with. This is a slightly different angle to my parent post, in this question I'm using the clang build (not the MSVC build), building the component build (successfully), and then importing the DLL into an MSVC project. I get five unresolved symbols detailed below. Why on earth would CLANG not export these symbols? Is there any way I might be able to fix this in V8?

__declspec(dllimport) public: void __cdecl v8::ObjectTemplate::SetIndexedPropertyHandler(void (__cdecl*)(unsigned int,class v8::PropertyCallbackInfo<class v8::Value> const &),void (__cdecl*)(unsigned int,class v8::Local<class v8::Value>,class v8::PropertyCallbackInfo<class v8::Value> const &),void (__cdecl*)(unsigned int,class v8::PropertyCallbackInfo<class v8::Integer> const &),void (__cdecl*)(unsigned int,class v8::PropertyCallbackInfo<class v8::Boolean> const &),void (__cdecl*)(class v8::PropertyCallbackInfo<class v8::Array> const &),class v8::Local<class v8::Value>)

__declspec(dllimport) public: __cdecl v8::Isolate::Scope::Scope(class v8::Isolate *)

__declspec(dllimport) public: __cdecl v8::Isolate::Scope::~Scope(void)

__declspec(dllimport) public: __cdecl v8::EscapableHandleScope::~EscapableHandleScope(void)

__declspec(dllimport) public: char * __cdecl v8::String::Utf8Value::operator*(void)

[Seth Brenith]

Hi Ben,

I believe that all of the issues you've seen are due to V8's reliance on the Clang-specific compiler flag /Zc:dllExportIncludes-. This flag says "if a function is both inline and declspec(dll(ex|im)port), then ignore the declspec part". This flag gave a nice speedup to Chromium component builds when it was introduced, but no trybots build without it, so building without that flag has been regularly broken since. When you try to link using MSVC, it dutifully tries to find the functions that are marked dllimport, but Clang never exported them due to this flag.

Some possibly useful resources:

LLVM post about this flag: http://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html?m=1

V8 bug about problems building without this flag: https://bugs.chromium.org/p/v8/issues/detail?id=9465&can=1&q=dllexportinlines&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars

Explanation of MSVC's behavior on inline dllexport functions: https://devblogs.microsoft.com/oldnewthing/20140109-00/?p=2123

Request to add this flag to MSVC: https://developercommunity.visualstudio.com/idea/374754/implement-zcdllexportinlines-aka-fvisibility-inlin.html

---

From: v8-...@googlegroups.com <v8-...@googlegroups.com> on behalf of Ben Ernst <boi...@gmail.com>
Sent: Friday, November 15, 2019 6:11 PM
To: v8-dev <v8-...@googlegroups.com>
Subject: [EXTERNAL] [v8-dev] Re: Intention to contribute, to fix MSVC "component build", broken from v7.2 onwards.

 

--
--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/ff6d54b0-c658-4e8c-bc4f-2fc73f5035c7%40googlegroups.com.

[Seth Brenith]

Correction: the flag name is /Zc:dllexportInlines-.

Also, a couple of other things I should mention for completeness:
- Attempting to link with a shared library that was built with a different toolchain is a recipe for maddening runtime errors unless that library takes great care to export only ABI-stable things, which V8 does not.
- The errors in your latest post were related to imported functions, but problems building without this flag often manifest as the linker complaining about unresolved external functions. This is because the linker is fine with functions being undefined if the function is never called, but a dllexport function needs a definition.

[Ben Ernst]

Thank you Seth for your detailed information.

When I attempt an MSVC build with "use_custom_libcxx=false", the build of "torque_base" still includes "-I../../buildtools/third_party/libc++/trunk/include" in the include path, which results in other errors. 

I'm having trouble working out where those include paths are calculated, so I can go about trying to fix it. Can anyone point me in the right direction?

[Jakob Kummerow]

If I manage to get this build working, would it be possible/practical/desirable to add this configuration to the CI build system long term? Dan did mention it's "not officially supported".

Technically it's certainly possible. We used to have MSVC bots back when that toolchain was officially supported. 

Realistically I assume it's unlikely that we would re-introduce such bots, unless there is sufficient demand for that build configuration that the project as a whole decides that it's worth the resources. (Given that it was apparently broken for a year without anyone complaining, it seems that not many people care.)

We consider the MSVC build "community-supported", so we are grateful that you are stepping up to provide this support, and we will be happy to accept (reasonable) patches to get that build working again! :-)

[mike.m...@rtssigns.com]

Yes please fix this.   And yes we care!

MSVC builds should have never been dropped in the first place.

Building V8 with the supported tool chain is a nightmare for windows developers.

It’s really a mess.

 

Mike Moening

--

--
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+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3Qaf8rjj0nnWZ-z-6MVVLKNiuT6EQbb_-OdeitCMkBBGQ%40mail.gmail.com.

[Seth Brenith]

Weird, I don't see that behavior on my machine. Could you please run gn desc . //:torque_base --blame in your GN build directory and reply with the include_dirs portion of the output from that command? Mine looks like this (which doesn't include any libc++ dirs):

include_dirs

  From //build/config/compiler:default_include_dirs

       (Added by //build/config/BUILDCONFIG.gn:429)

    //

    //out.gn/msvc/gen/

  From //:internal_config

       (Added by //BUILD.gn:3355)

    //

    //out.gn/msvc/gen/

[Ben Ernst]

Jakob, 

I do think it's a leap to assume no-one cares. I don't update very frequently. Every time I update V8 it's a real investment in time because the API frequently changes. Since 7.1 (last working version), I'd stopped updating V8 because I figured the community had broken something that would eventually get fixed by goblins. I didn't get the memo about dropping support for MSVC. I get my news from the blog https://v8.dev/blog/

Ben

[Ben Ernst]

Seth, my output seems to be equivalent to yours. Included here. I'll run a clean build and repeat.

Ben.

include_dirs

  From //build/config/compiler:default_include_dirs

       (Added by //build/config/BUILDCONFIG.gn:429)

    //

    //out.gn/x64.release/gen/

  From //:internal_config

       (Added by //BUILD.gn:3358)

    //

    //out.gn/x64.release/gen/

[Ben Ernst]

I'm encountering a very different issue now with a clean build. The interesting part follows, and I attached a file with a more complete error message. I get many messages like this, complaining about object definitions not being available to class-definitions-tq.h. The error message seems to be legitimate. Can someone tell me, how are these -tq.h files generated? The answer seems to involve something called "torque". How would I go about telling "torque" where to find the missing headers? This problem doesn't seem to have anything to do with MSVC though, so I can't figure out why clang builds wouldn't be having the same error.

     [exec] C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include\type_traits(616): error C2139: 'v8::internal::Cell': an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_convertible_to'

     [exec] C:\fd22cbe1\v8\out.gn\x64.release\gen\torque-generated/class-definitions-tq.h(78): note: see declaration of 'v8::internal::Cell'

[Ben Ernst]

Would anyone have any advice on how to get torque to see these type definitions? I've attached a longer excerpt of the errors I get, and my "args.gn". I'm building component build under MSVC.

[Ben Ernst]

I'm building clang component build today, (that one's supported right?) from 7.9-lkgr. I'm sure I built 7.8-lkgr the other day, and that was fine, but on 7.9 I get this unresolved symbol that might be related to std::shared_ptr. My args.gn is all default settings for x64.release except v8_enable_i18n_support=false. Any ideas?

     [exec] [833/840] STAMP obj/v8_external_snapshot.inputdeps.stamp

     [exec] [834/840] CXX obj/v8_external_snapshot/embedded.obj

     [exec] [835/840] CXX obj/v8_external_snapshot/natives-external.obj

     [exec] [836/840] CXX obj/v8_external_snapshot/setup-isolate-deserialize.obj

     [exec] [837/840] CXX obj/v8_external_snapshot/snapshot-external.obj

     [exec] [838/840] STAMP obj/v8_external_snapshot.stamp

     [exec] [839/840] STAMP obj/v8_maybe_snapshot.stamp

     [exec] [840/840] LINK(DLL) v8.dll v8.dll.lib v8.dll.pdb

     [exec] FAILED: v8.dll v8.dll.lib v8.dll.pdb

     [exec] ninja -t msvc -e environment.x64 -- ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo "-libpath:..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\ATLMFC\lib\x64" "-libpath:..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\lib\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64" "-libpath:..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\ATLMFC\lib\x64" "-libpath:..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\lib\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x64" "-libpath:..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64" /IMPLIB:./v8.dll.lib /DLL /OUT:./v8.dll /PDB:./v8.dll.pdb @./v8.dll.rsp

     [exec] lld-link: error: undefined symbol: __declspec(dllimport) public: void __cdecl std::__1::__shared_count::__add_shared(void)

     [exec] >>> referenced by .\..\..\include\v8.h:4614

     [exec] >>>               obj/v8/v8dll-main.obj:(public: __cdecl v8::CompiledWasmModule::CompiledWasmModule(class v8::CompiledWasmModule const &))

     [exec] >>> referenced by .\..\..\include\v8.h:4614

     [exec] >>>               obj/v8/v8dll-main.obj:(public: __cdecl v8::CompiledWasmModule::CompiledWasmModule(class v8::CompiledWasmModule &&))

     [exec]

     [exec] lld-link: error: undefined symbol: __declspec(dllimport) public: bool __cdecl std::__1::__shared_count::__release_shared(void)

     [exec] >>> referenced by .\..\..\include\v8.h:4614

     [exec] >>>               obj/v8/v8dll-main.obj:(public: __cdecl v8::CompiledWasmModule::~CompiledWasmModule(void))

     [exec] >>> referenced by .\..\..\include\v8.h:4787

     [exec] >>>               obj/v8/v8dll-main.obj:(public: __cdecl v8::WasmModuleObjectBuilderStreaming::~WasmModuleObjectBuilderStreaming(void))

     [exec] >>> referenced by .\..\..\include\v8.h:4797

     [exec] >>>               obj/v8/v8dll-main.obj:(private: class v8::WasmModuleObjectBuilderStreaming & __cdecl v8::WasmModuleObjectBuilderStreaming::operator=(class v8::WasmModuleObjectBuilderStreaming &&))

     [exec] ninja: build stopped: subcommand failed.

Removed symlink "C:\fce98c51".