Is #2 not addressed by use_custom_libcxx = false in args.gn? At least on
Linux, that causes the default system libstdc++ to be used.


On Mon, Mar 16, 2020 at 7:32 PM 'Bill Ticehurst' via v8-dev <
[email protected]> wrote:

> I thought I'd posted before on why this is a problem currently, but can't
> find it. To summarize the major points:
>
> 1. Clang builds with flags MSVC doesn't support - specifically,
> /Zc:dllexportInlines- can cause issues with component builds. (As Clang
> won't export __declspec(dllexport) functions that have an inline
> definition, but MSVC may still try to import them - especially on debug
> builds where it inlines less). Maybe this is the missing symbols issues you
> hit, Chris?
> 2. While the compiler may try to be ABI compatible, the libc++ standard
> library from LLVM that V8 uses by default isn't compatible with the MSVC
> C++ standard runtime library, and some APIs expose C++ STL types.
>
> Arguable both of these could be cleaned up in the codebase to where they
> aren't a problem, but right now they are. (#1 probably isn't an issue if
> building a static library to link in, but #2 still would be).
>
>  - Bill
>
> On Sunday, March 15, 2020 at 5:58:24 PM UTC-7, Chris Fischer wrote:
>>
>> That was my thought as well.  However, when I successfully built V8 with
>> CLANG and then tried to build our application with MSVC 2017 it failed in
>> the link process with missing symbols.  Rebuilding the same version of V8
>> with MSVC (and fixing a few compiler errors and warnings for that to work)
>> produced new binaries that resolved the linker errors.
>>
>>
>> On Sunday, March 15, 2020 at 5:54:51 AM UTC-4, Ben Noordhuis wrote:
>>>
>>> On Sat, Mar 14, 2020 at 3:03 PM Chris Fischer <[email protected]>
>>> wrote:
>>> >
>>> > I'd like to chime in for continued support of MSVC (with build
>>> regression automated tests).  We embed V8 in a large project with many
>>> third party code components.  Many of these components are not available as
>>> source so building with CLANG is not viable.  We currently use V8 as a
>>> component build (DLL) but could also use V8 as a static library compiled
>>> with /MD.  In general, most of our third party software comes with these
>>> too variants (static & dynamic libraries with /MD runtime).
>>> >
>>> > I'd be happy to help in contributing / maintaining MSVC support but
>>> would need a primer on contributing and and some contacts as sounding
>>> boards for feedback and brainstorming.
>>> >
>>> > Chris Fischer
>>>
>>> I don't have a stake in this and I don't want to derail the
>>> conversation but the clang-cl frontend is ABI-compatible with cl.exe
>>> these days, isn't it? You don't even need to use it for all of your
>>> project, just V8.
>>>
>> --
> --
> 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/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-dev/927d7546-969b-4243-a9f1-4802c3301924%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
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/CAKSzg3QPZwW8i-M-MjXZNgvcm40bbEL6n573rfQ1t9oQwz6Pqg%40mail.gmail.com.

Reply via email to