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/689147ae-b23c-4d0e-9ef1-063832384338n%40googlegroups.com.
