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
[email protected]
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-dev/9e1979e8-604a-4a9a-ab4a-d74ffb53acee%40googlegroups.com.
