Unable to build newer v8 code for embedding

[Jay Hayes]

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!

[Jakob Kummerow]

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.)

--

[Jay Hayes]

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 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!

[Jakob Kummerow]

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.

--
--
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.

[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.

[Xingwang Liao]

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

[Jakob Kummerow]

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.

[Juan dos Santos]

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  

[Juan dos Santos]

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