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".
On Wednesday, 20 November 2019 12:03:41 UTC+8, Ben Ernst wrote:
>
> 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.
>
> On Tuesday, 19 November 2019 21:28:26 UTC+8, Ben Ernst wrote:
>>
>> 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'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, 19 November 2019 20:10:47 UTC+8, Ben Ernst wrote:
>>>
>>> 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/
>>>
>>> On Tuesday, 19 November 2019 00:57:59 UTC+8, Seth Brenith wrote:
>>>>
>>>> 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/
>>>>
>>>>
>>>> On Sunday, November 17, 2019 at 9:10:23 PM UTC-8, Ben Ernst wrote:
>>>>>
>>>>> 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?
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, 17 November 2019 00:15:53 UTC+8, Seth Brenith wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
--
--
v8-dev mailing list
v8-dev@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/f02750e3-0a99-4347-bd0c-1bdffed02a79%40googlegroups.com.
