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/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 [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/c4f51d8d-db73-4d34-86c1-155dfe1da124n%40googlegroups.com.
