As I wrote upthread, you need to use the same standard library consistently. Use either -stdlib=libstdc++ to link your project against libstdc++, or the GN arg use_custom_libcxx = false to link V8 against your system's libc++. We support and test only the former, the latter may be easier depending on your project setup.
On Fri, Aug 8, 2025 at 6:42 PM Xingwang Liao <[email protected]> wrote: > Hi everyone, > > I'm trying to build V8 monolithic version *13.9.205.16* and am running > into some linker errors. > > Here are my args.gn: > ``` > dcheck_always_on=false > is_component_build=false > is_debug=false > target_cpu="x64" > v8_monolithic=true > v8_use_external_startup_data=false > v8_enable_temporal_support=false > ``` > > And this is the output when I try to build a "hello world" sample: > ``` > clang++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti > -fuse-ld=lld -lv8_monolith -lv8_libbase -lv8_libplatform > -Lout.gn/Linux.x64.release/o > bj/ -pthread -std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX > ld.lld: error: undefined symbol: v8::platform::NewDefaultPlatform(int, > v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, > std::unique_ptr<v8::TracingController, > std::default_delete<v8::TracingController>>, v8::platform::PriorityMode) > >>> referenced by hello-world.cc > >>> /tmp/hello-world-87a9ec.o:(main) > > ld.lld: error: undefined symbol: std::__Cr::ios_base::init(void*) > >>> referenced by logging.cc > >>> logging.o:(std::__Cr::basic_string<char, > std::__Cr::char_traits<char>, std::__Cr::allocator<char>>* > v8::base::MakeCheckOpString<int, int>(int, int, char const*)) in archive > out.gn/Linux.x64.release/obj/libv8_monolith.a > >>> referenced by logging.cc > >>> logging.o:(std::__Cr::basic_string<char, > std::__Cr::char_traits<char>, std::__Cr::allocator<char>> > v8::base::detail::PrintToString<int>(int&&)) in archive > out.gn/Linux.x64.release/obj/libv8_monolith.a > >>> referenced by logging.cc > >>> logging.o:(std::__Cr::basic_string<char, > std::__Cr::char_traits<char>, std::__Cr::allocator<char>>* > v8::base::MakeCheckOpString<long, long>(long, long, char const*)) in > archive out.gn/Linux.x64.release/obj/libv8_monolith.a > >>> referenced 100 more times > [.....] > ``` > > It seems there are some *undefined symbols*, specifically related > to v8::platform::NewDefaultPlatform and some std library components. > > Has anyone encountered this issue or know what might be causing it? > > Thanks > > 在2025年6月9日星期一 UTC+8 23:13:27<Jay Hayes> 写道： > >> Looks like the hello_world example now requires the rust rlibs to be >> included when linking if v8_enable_temporal_support is set to true so >> that answers that question. >> >> I was able to track down why 13.8 (13.8.258.2) doesn't build successfully >> when using gcc/libstdc++ but I don't understand what exactly is causing the >> issue. >> >> Originally when I attempted to build 13.8 (13.8.258.2) with >> gcc/libstdc++, the *mksnapshot* target would fail during linking with: >> undefined reference to >> `rust_allocator_internal::alloc_error_handler_impl()' >> >> If I manually edit the generated >> out.gn/x64.release.sample/obj/mksnapshot.ninja and add >> obj/build/rust/allocator/liballoc_error_handler_impl.a to the rlibs >> section, the build succeeds and I can compile and link the hello_world >> example to v8 as well. >> >> My confusion is due to the fact the generated mksnapshot.ninja (for both >> gcc/libstdc++ and clang/libcxx) contains >> obj/build/rust/allocator/liballoc_error_handler_impl.a within: >> build ./mksnapshot: link obj/mksnapshot/builtins-effects-dummy.o >> <...> >> obj/build/rust/allocator/liballoc_error_handler_impl.a >> <...> >> >> yet gcc/libstdc++ fails during linking without the manual rlib edit to >> mksnapshot.ninja. >> On Friday, June 6, 2025 at 5:45:49 AM UTC-4 Jakob Kummerow wrote: >> >>> The build system does not care about directory names, only GN args >>> matter. >>> >>> Using the same standard library is probably much more important than >>> using the same compiler; but if it ever happens that using Clang fixes an >>> issue that occurs when using GCC, then that's our recommended solution. >>> >>> The temporal_rs stuff is pretty new, `gclient sync` should download what >>> you need at the version you need it. >>> >>> And yes, someone should update the embedding guide again... I'd hope >>> it's enough to simply replace the compiler binary name on the command line. >>> >>> >>> On Thu, Jun 5, 2025 at 10:17 PM Jay Hayes <[email protected]> wrote: >>> >>>> Thank you for the info. My copy/paste of the gn config from the post I >>>> referenced into the x64.*release *directory somehow made me blind to >>>> the fact is_debug was set to true. >>>> >>>> I also didn't realize we would have to compile the rest of our app with >>>> clang if we were linking to the static v8 libs. Maybe that explains why I >>>> was getting the original link error when trying to build the hello_world >>>> example using g++: >>>> ld.lld: error: undefined symbol: v8::platform::NewDefaultPlatform(int, >>>> v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, >>>> std::unique_ptr<v8::TracingController, >>>> std::default_delete<v8::TracingController>>, v8::platform::PriorityMode) >>>> >>> referenced by hello-world.cc >>>> >>> /tmp/hello-world-901944.o:(main) >>>> >>>> Using the following config: >>>> dcheck_always_on = false >>>> is_component_build = false >>>> is_debug = false >>>> target_cpu = "x64" >>>> v8_monolithic = true >>>> v8_use_external_startup_data = false >>>> >>>> I am able to build 13.8 (13.8.258.2) successfully and, if I use clang >>>> and the custom libcxx library, I can almost build the hello_world example; >>>> seems I missing this temporal_rs lib somehow: >>>> ld.lld: error: undefined symbol: temporal_rs_Instant_epoch_milliseconds >>>> >>> referenced by js-date-time-format.cc >>>> >>> js-date-time-format.o:(v8::internal::(anonymous >>>> namespace)::HandleDateTimeTemporalInstant(v8::internal::Isolate*, >>>> icu_74::SimpleDateFormat const&, >>>> v8::internal::DirectHandle<v8::internal::JSTemporalInstant>, char const*)) >>>> in archive out.gn/x64.release.sample/obj/libv8_monolith.a >>>> >>>> If I add v8_enable_temporal_support = false to the config and >>>> rebuild, then the hello_world example builds/runs successfully and is 49 MB >>>> (vs. 3.3 GB) :) >>>> >>>> The embedding guide <https://v8.dev/docs/embed> still uses g++, could >>>> you provide the correct way to build the example with clang as I'm curious >>>> why this temporal_rs is an issue when linking? >>>> >>>> Thanks! >>>> On Thursday, June 5, 2025 at 6:27:39 AM UTC-4 Jakob Kummerow wrote: >>>> >>>>> The binary size is caused by `is_debug = true`. That configuration is >>>>> very useful for debugging, but is both slow and large. For release-mode >>>>> binaries, set `is_debug = false`. >>>>> >>>>> Regarding `is_clang` and `use_custom_libcxx`: Drop them both to get >>>>> the configuration we test and support. You will then also need to compile >>>>> the rest of your application with clang and libstdc++, which is an >>>>> obstacle >>>>> for some projects. Alternatively, you can continue to use g++ and libc++ >>>>> and hope that it works, or debug/fix it when it doesn't. We'd probably >>>>> even >>>>> accept reasonably non-intrusive patches for upstreaming. >>>>> >>>>> Remember to run `gclient sync` after checking out a different git >>>>> commit. (I'm not sure whether that explains your 13.8 difficulties.) >>>>> >>>>> >>>>> On Wed, Jun 4, 2025 at 8:06 PM Jay Hayes <[email protected]> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We are experimenting with building v8 for embedding within our c++ >>>>>> application. >>>>>> >>>>>> Following the guidance - https://v8.dev/docs/embed, it seems the doc >>>>>> is for 13.1. When I try to builder newer code using the >>>>>> *x64.release.sample* config, the build fails very quickly: >>>>>> ../../src/base/vector.h:296:32: error: no member named >>>>>> 'make_unique_for_overwrite' in namespace 'std' >>>>>> >>>>>> I then discovered this issue - >>>>>> https://issues.chromium.org/issues/377222400 which speaks to the >>>>>> fact the doc might be out of date. >>>>>> >>>>>> Using the suggested config from the linked issue above: >>>>>> >>>>>> target_cpu = "x64" >>>>>> target_os = "linux" >>>>>> is_debug = true >>>>>> is_component_build = false >>>>>> v8_monolithic = true >>>>>> v8_static_library = false >>>>>> v8_use_external_startup_data = false >>>>>> use_custom_libcxx = false >>>>>> is_clang = false >>>>>> treat_warnings_as_errors = false >>>>>> >>>>>> $ ninja -v -C out.gn/x64.release v8_monolith >>>>>> >>>>>> $ g++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti >>>>>> -fuse-ld=lld -lv8_monolith -lv8_libbase -lv8_libplatform >>>>>> -Lout.gn/x64.release/obj/ -pthread -std=c++20 -DV8_COMPRESS_POINTERS >>>>>> -DV8_ENABLE_SANDBOX >>>>>> >>>>>> I was able to compile 13.7 (13.7.152.8) on ubuntu 24.04 and link the >>>>>> hello world example to the v8 static libs however I noticed the >>>>>> hello_world >>>>>> executable (which did run successfully) was a whopping 3.3 GB? >>>>>> >>>>>> Trying to build 13.8 (13.8.258.2) using the same config fails to >>>>>> build successfully: >>>>>> FAILED: mksnapshot >>>>>> "python3" "../../build/toolchain/gcc_link_wrapper.py" >>>>>> --output="./mksnapshot" -- g++ -pie -Wl,--fatal-warnings -Wl,--build-id >>>>>> -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -m64 -Wl,-z,defs >>>>>> -Wl,--as-needed --sysroot=../../build/linux/debian_bullseye_amd64-sysroot >>>>>> -rdynamic -pie -Wl,--disable-new-dtags -Wl,--gc-sections -o >>>>>> "./mksnapshot" >>>>>> -Wl,--start-group @"./mksnapshot.rsp" -Wl,--end-group -latomic -ldl >>>>>> -lpthread -lrt -Wl,--start-group >>>>>> <<<truncated for brevity>>> >>>>>> /usr/bin/ld: >>>>>> obj/build/rust/allocator/libbuild_srust_sallocator_callocator.rlib(libbuild_srust_sallocator_callocator.build_srust_sallocator_callocator.ff715ce24295f21e-cgu.0.rcgu.o): >>>>>> in function `__rustc::__rust_alloc_error_handler': >>>>>> ./../../build/rust/allocator/lib.rs:106:(.text._RNvCsiiodXzYB6cW_7___rustc26___rust_alloc_error_handler+0x10): >>>>>> undefined reference to >>>>>> `rust_allocator_internal::alloc_error_handler_impl()' >>>>>> collect2: error: ld returned 1 exit status >>>>>> ninja: build stopped: subcommand failed. >>>>>> >>>>>> Currently some of the gn config args used that enables v8 (v13.7) to >>>>>> build and link the example successfully are doc'd as deprecated: >>>>>> use_custom_libcxx = false >>>>>> is_clang = false >>>>>> >>>>>> I've read other posts that mention clang is the only compiler >>>>>> supported moving forward which furthers my belief I'm using an incorrect >>>>>> build configuration. >>>>>> >>>>>> My question is what is the correct gn config one should use to build >>>>>> the latest (13.8) v8 code and be able to link the hello world example >>>>>> successfully? >>>>>> >>>>>> Thanks in advance for any suggestions/guidance! >>>>>> >>>>>> -- >>>>>> >>>>> -- >>> >>> -- -- 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 visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3TYDxYR5HnMycoiD%3DmiZ_pqHwCQrsQfVG%3DP-vkg3nv1kA%40mail.gmail.com.
