is_component_build=true, use_custom_libcxx=false on Windows

[Chris Hillery]

I've been trying everything I can think of to build a DLL version of v8 which does not depend on the v8-supplied libc++ . As I understand it, this is the necessary configuration if I want to link v8 into a larger application that is built with other C++ libraries which use a different C++ standard library - in my case, an application built using MSVC.

It seems that I need is_component_build=true to generate .dlls, and use_custom_libcxx=false to avoid building/linking against v8's libc++. However every time I've tried this, seemingly regardless of what other settings I enable or disable or whatever else I try (many many things at this point), it fails linking abseil:

[734/2344] LINK(DLL) third_party_abseil-cpp_absl.dll third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
FAILED: third_party_abseil-cpp_absl.dll third_party_abseil-cpp_absl.dll.lib third_party_abseil-cpp_absl.dll.pdb
..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe "/OUT:./third_party_abseil-cpp_absl.dll" /nologo -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\18\lib\windows "-libpath:../../../../../../../Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.36.32532/ATLMFC/lib/x64" "-libpath:../../../../../../../Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.36.32532/lib/x64" "-libpath:../../../../../../../Program Files (x86)/Windows Kits/NETFXSDK/4.8/lib/um/x64" "-libpath:../../../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/ucrt/x64" "-libpath:../../../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/um/x64" /MACHINE:X64  "/IMPLIB:./third_party_abseil-cpp_absl.dll.lib" /DLL "/PDB:./third_party_abseil-cpp_absl.dll.pdb" "@./third_party_abseil-cpp_absl.dll.rsp"
lld-link: error: <root>: undefined symbol: public: __cdecl absl::Condition::Condition<struct std::__Cr::atomic<bool> const>(bool (__cdecl *)(struct std::__Cr::atomic<bool> const *), struct std::__Cr::atomic<bool> const *)
lld-link: error: <root>: undefined symbol: public: __cdecl absl::container_internal::internal_compressed_tuple::Storage<struct absl::cord_internal::CordRep **, 1, 0>::Storage<struct absl::cord_internal::CordRep **, 1, 0><std::nullptr_t>(struct std::__Cr::in_place_t, std::nullptr_t &&)
lld-link: error: <root>: undefined symbol: public: __cdecl absl::container_internal::internal_compressed_tuple::Storage<class absl::LogSink **, 1, 0>::Storage<class absl::LogSink **, 1, 0><std::nullptr_t>(struct std::__Cr::in_place_t, std::nullptr_t &&)
lld-link: error: <root>: undefined symbol: public: __cdecl absl::container_internal::internal_compressed_tuple::Storage<struct absl::status_internal::Payload *, 1, 0>::Storage<struct absl::status_internal::Payload *, 1, 0><std::nullptr_t>(struct std::__Cr::in_place_t, std::nullptr_t &&)
lld-link: error: <root>: undefined symbol: public: __cdecl std::__Cr::__compressed_pair<class absl::time_internal::cctz::time_zone::Impl const ***, class std::__Cr::allocator<class absl::time_internal::cctz::time_zone::Impl const **> &>::__compressed_pair<class absl::time_internal::cctz::time_zone::Impl const ***, class std::__Cr::allocator<class absl::time_internal::cctz::time_zone::Impl const **> &><std::nullptr_t, class std::__Cr::allocator<class absl::time_internal::cctz::time_zone::Impl const **> &>(std::nullptr_t &&, class std::__Cr::allocator<class absl::time_internal::cctz::time_zone::Impl const **> &)

...and quite a lot of similar errors.

I have MSVC 2022 Professional installed, with Windows 11 SDK (10.0.22621.0) installed along with the Debugging Tools, as well as the ATL and MFC components. 

Can anyone help me get past this issue, or even just explain what the enormous error message means? 

Thanks,

Ceej

aka Chris Hillery

[Chris Hillery]

I should mention that I've tried building v8 12.1.285.26; 12.2.247; as well as whatever "fetch v8" brings me, all with the same error. However in the past, I've built v8 11.6.189.8 with the same gn configuration options successfully.

Ceej

aka Chris Hillery

[Andreas Beil]

Hi Chris,

i observe the same problem now for a while and did not manage to solve it.

But what i observed: The 'monolith' configuration (is_component_build=false) works.

[Ben Ernst]

Chris
I myself gave up on DLL version many years ago after many further years of significant pain. The DLL configuration is consistently broken. The team is very responsive, and problems are fixed quickly, but something else quickly breaks soon after. I migrated to the "monolith" build, and I isolate calls to V8 to a single one of my own DLLs. This has been a sustainable approach for me.

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/dda35890-2e2c-4e9f-8b57-e86966ba2ad4n%40googlegroups.com.