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 <jacky...@gmail.com> 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 <jacky...@gmail.com> 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 >>> v8-...@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+un...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/v8-dev/c81e2a4a-41f6-4425-9a2e-d90fbab36c81n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/c81e2a4a-41f6-4425-9a2e-d90fbab36c81n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- 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 visit https://groups.google.com/d/msgid/v8-dev/7d587c64-5ead-4616-8e4a-2a19cbdac999n%40googlegroups.com.
