I found a solution, de args.gn parameters for x64 compatible with g++ o gcc are:
target_os="linux" target_cpu="x64" v8_target_cpu="x64" is_debug=false dcheck_always_on=false is_clang=false is_component_build=false strip_debug_info=true symbol_level=0 treat_warnings_as_errors=false use_custom_libcxx=false v8_enable_gdbjit=false v8_enable_i18n_support=false v8_enable_pointer_compression=false v8_enable_test_features=false v8_monolithic=true v8_use_external_startup_data=false clang_use_chrome_plugins=false enable_rust=false target_sysroot_dir="" use_rtti=false use_sysroot=false v8_deprecation_warnings=false v8_enable_builtins_optimization=true v8_enable_sandbox=false v8_enable_snapshot_compression=false v8_enable_temporal_support=false v8_imminent_deprecation_warnings=false I think these parameters make the magic "is_clang=false enable_rust=false use_sysroot=false target_sysroot_dir="" " but use all of them. I found this great page with the solution here: https://github.com/just-js/v8/blob/main/args.linux.x64.gn There are all the "args.gn" configuration for different platforms. When I did the compilation only found one warning, nothing important. Juan dos Santos El lunes, 25 de agosto de 2025 a las 8:03:43 UTC-3, Juan dos Santos escribió: > Hi everyone! > I have a similar issue, when I make the config files with v8gen I think > something happen with the libstdc++ because the error "std::bit_cast" not > found must be for -std=c++20 no defined but I think is defined, I don't > know really, please can you give me a hand ? > > Commands: > > tools/dev/v8gen.py x64.release.sample > autoninja -C out.gn/x64.release.sample/ v8_monolith > > Result: > > offline mode > ninja: Entering directory `out.gn/x64.release.sample/' > 2.01s load siso config > [1621/3672] 2m10.11s F CXX obj/torque_base/utils.o > FAILED: 8b1561ec-f17b-4ae5-b401-647b0752f4f7 "./obj/torque_base/utils.o" > CXX obj/torque_base/utils.o > err: exit=1 > ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF > obj/torque_base/utils.o.d -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS > -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -DCR_CLANG_REVISION=\"llvmorg-21-init-16348-gbd809ffb-17\" > -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE > -D_GLIBCXX_ASSERTIONS=1 -DCR_SYSROOT_KEY=20250129T203412Z-1 -DUSE_UDEV > -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DNDEBUG -DNVALGRIND > -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 > -DENABLE_GDB_JIT_INTERFACE -DV8_INTL_SUPPORT -DV8_TEMPORAL_SUPPORT > -DV8_ATOMIC_OBJECT_FIELD_WRITES -DV8_ENABLE_LAZY_SOURCE_POSITIONS > -DV8_WIN64_UNWINDING_INFO -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH > -DV8_ENABLE_FUZZTEST -DV8_SHORT_BUILTIN_CALLS -DV8_EXTERNAL_CODE_SPACE > -DV8_ENABLE_SPARKPLUG -DV8_ENABLE_MAGLEV -DV8_ENABLE_TURBOFAN > -DV8_ENABLE_WEBASSEMBLY -DV8_ENABLE_CONTINUATION_PRESERVED_EMBEDDER_DATA > -DV8_ALLOCATION_FOLDING -DV8_ALLOCATION_SITE_TRACKING > -DV8_ADVANCED_BIGINT_ALGORITHMS -DV8_STATIC_ROOTS -DV8_USE_ZLIB > -DV8_USE_LIBM_TRIG_FUNCTIONS -DV8_ENABLE_WASM_SIMD256_REVEC > -DV8_ENABLE_MAGLEV_GRAPH_PRINTER -DV8_ENABLE_BUILTIN_JUMP_TABLE_SWITCH > -DV8_ENABLE_EXTENSIBLE_RO_SNAPSHOT -DV8_ENABLE_BLACK_ALLOCATED_PAGES > -DV8_ENABLE_LEAPTIERING -DV8_WASM_RANDOM_FUZZERS > -DV8_ARRAY_BUFFER_INTERNAL_FIELD_COUNT=0 > -DV8_ARRAY_BUFFER_VIEW_INTERNAL_FIELD_COUNT=0 > -DV8_PROMISE_INTERNAL_FIELD_COUNT=0 -DV8_USE_DEFAULT_HASHER_SECRET=true > -DV8_COMPRESS_POINTERS -DV8_COMPRESS_POINTERS_IN_SHARED_CAGE > -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_ENABLE_SANDBOX -DV8_DEPRECATION_WARNINGS > -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_HAVE_TARGET_OS -DV8_TARGET_OS_LINUX > -DCPPGC_CAGED_HEAP -DCPPGC_YOUNG_GENERATION -DCPPGC_POINTER_COMPRESSION > -DCPPGC_ENABLE_LARGER_CAGE -DCPPGC_SLIM_WRITE_BARRIER -DV8_TARGET_ARCH_X64 > -DV8_RUNTIME_CALL_STATS -DABSL_ALLOCATOR_NOTHROW=1 -I../.. -Igen > -I../../include -Igen/include -I../../third_party/abseil-cpp -Wall -Wextra > -Wimplicit-fallthrough -Wextra-semi -Wunreachable-code-aggressive -Wgnu > -Wno-gnu-anonymous-struct -Wno-gnu-conditional-omitted-operand > -Wno-gnu-include-next -Wno-gnu-label-as-value -Wno-gnu-redeclared-enum > -Wno-gnu-statement-expression -Wno-gnu-zero-variadic-macro-arguments > -Wno-zero-length-array -Wthread-safety -Wno-missing-field-initializers > -Wno-unused-parameter -Wno-psabi -Wloop-analysis > -Wno-unneeded-internal-declaration -Wno-cast-function-type > -Wno-thread-safety-reference-return -Wno-nontrivial-memcall -Wshadow > -Werror -fno-delete-null-pointer-checks -fno-strict-overflow -fno-ident > -fno-math-errno -fno-strict-aliasing -fstack-protector -funwind-tables > -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants > -fno-sized-deallocation > -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm > -instcombine-lower-dbg-declare=0 -mllvm > -split-threshold-for-reg-with-hint=0 -ffp-contract=off > -Wa,--crel,--allow-experimental-crel --target=x86_64-unknown-linux-gnu > -msse3 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= > -D__TIMESTAMP__= -ffile-compilation-dir=. -no-canonical-prefixes -Xclang > -fmodule-file-home-is-cwd -fno-omit-frame-pointer -g0 -Wheader-hygiene > -Wstring-conversion -Wtautological-overlap-compare -Wunreachable-code > -Wctad-maybe-unsupported -Xclang -add-plugin -Xclang blink-gc-plugin > -Wno-invalid-offsetof -Wshorten-64-to-32 -Wmissing-field-initializers > -Wunnecessary-virtual-specifier -O3 -fdata-sections -ffunction-sections > -fno-unique-section-names -fvisibility=default -Wexit-time-destructors > -Wno-invalid-offsetof -Wenum-compare-conditional > -Wno-nullability-completeness -std=c++20 -Wno-trigraphs > -gsimple-template-names > --sysroot=../../build/linux/debian_bullseye_amd64-sysroot -fexceptions > -frtti -c ../../src/torque/utils.cc -o obj/torque_base/utils.o > build step: cxx "./obj/torque_base/utils.o" > siso_rule: clang/cxx > stderr: > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:18:10: error: no template named 'bit_cast' > in namespace 'std'; did you mean simply 'bit_cast'? > 18 | return std::bit_cast<uint64_t>(d); > | ^~~~~~~~~~~~~ > | bit_cast > ../../src/base/macros.h:137:16: note: 'bit_cast' declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:18:10: error: no template named 'bit_cast' > in namespace 'std'; did you mean simply 'bit_cast'? > 18 | return std::bit_cast<uint64_t>(d); > | ^~~~~~~~~~~~~ > | bit_cast > ../../src/base/macros.h:137:16: note: 'bit_cast' declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:17:27: error: constexpr function never > produces a constant expression [-Winvalid-constexpr] > 17 | inline constexpr uint64_t double_to_uint64(double d) { > | ^~~~~~~~~~~~~~~~ > ../../src/base/numbers/double.h:18:10: note: non-constexpr function > 'bit_cast<unsigned long, double>' cannot be used in a constant expression > 18 | return std::bit_cast<uint64_t>(d); > | ^ > ../../src/base/macros.h:137:16: note: declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:21:10: error: no template named 'bit_cast' > in namespace 'std'; did you mean simply 'bit_cast'? > 21 | return std::bit_cast<double>(d64); > | ^~~~~~~~~~~~~ > | bit_cast > ../../src/base/macros.h:137:16: note: 'bit_cast' declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:21:10: error: no template named 'bit_cast' > in namespace 'std'; did you mean simply 'bit_cast'? > 21 | return std::bit_cast<double>(d64); > | ^~~~~~~~~~~~~ > | bit_cast > ../../src/base/macros.h:137:16: note: 'bit_cast' declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > In file included from ../../src/torque/utils.cc:15: > In file included from ../../src/torque/ast.h:17: > In file included from ../../src/numbers/integer-literal.h:10: > In file included from ../../src/common/globals.h:22: > ../../src/base/numbers/double.h:20:25: error: constexpr function never > produces a constant expression [-Winvalid-constexpr] > 20 | inline constexpr double uint64_to_double(uint64_t d64) { > | ^~~~~~~~~~~~~~~~ > ../../src/base/numbers/double.h:21:10: note: non-constexpr function > 'bit_cast<double, unsigned long>' cannot be used in a constant expression > 21 | return std::bit_cast<double>(d64); > | ^ > ../../src/base/macros.h:137:16: note: declared here > 137 | V8_INLINE Dest bit_cast(Source const& source) { > | ^ > 6 errors generated. > > build failed > local:1622 remote:0 cache:0 cache-write:0(err:0) fallback:0 retry:0 > skip:228 > fs: ops: 79691(err:9091) / r:6974(err:0) 458.69MiB / w:1134(err:0) > 124.94MiB > resource/capa used(err) wait-avg | s m | serv-avg | s m | > localexec/8 468(1) 1m04.64s |▂ ▂▂▆█ | 2.09s | ▂▂█ ▂ | > > 2m10.34s Build Failure: 1622 done 1 failed 2050 remaining - 12.44/s > 1 steps failed: exit=1 > see ./out.gn/x64.release.sample/siso_output for full command line and > output > or ./out.gn/x64.release.sample/siso.INFO > use ./out.gn/x64.release.sample/siso_failed_commands.sh to re-run failed > commands > > El viernes, 8 de agosto de 2025 a las 13:52:58 UTC-3, Jakob Kummerow > escribió: > >> 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/86f11631-06cc-46b4-bde5-e64c7274c347n%40googlegroups.com.
