I verified locally that d8 built with is_component_build = false is_debug = true v8_optimized_debug = true use_custom_libcxx = false
on a macbook works fine. The build completes, and d8 runs some trivial examples without issues. Same with v8_cppgc_shared_unittests which you mentioned in your latest email. I would try starting over with a clean checkout, building d8 with the gn flags above. If something still doesn't work, please file a bug at crbug.com/v8/new with exact reproduction steps. On Mon, Oct 12, 2020 at 7:47 PM Cameron Caturria < surviving.deceptive.wo...@gmail.com> wrote: > Hi, > v8_optimized_debug = false gives the following: > > ninja: Entering directory `out.gn/x64.release' > [1/1] Regenerating ninja files > [1184/2682] LINK ./v8_cppgc_shared_unittests > FAILED: v8_cppgc_shared_unittests > TOOL_VERSION=1602521620 ../../build/toolchain/mac/linker_driver.py > > -Wcrl,strippath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip > ../../third_party/llvm-build/Release+Asserts/bin/clang++ -B > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ > -Wl,-fatal_warnings -stdlib=libc++ -arch x86_64 -Werror -isysroot > > ../../../../../Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk > -mmacosx-version-min=10.10.0 -Wl,-ObjC -Wl,-rpath,@loader_path/. > -Wl,-rpath,@loader_path/../../.. -o "./v8_cppgc_shared_unittests" > -Wl,-filelist,"./v8_cppgc_shared_unittests.rsp" > ./libv8_cppgc_shared_for_testing.dylib ./libv8_libbase.dylib > ld: warning: direct access in function > 'testing::internal::SuiteApiResolver<testing::internal::(anonymous > namespace)::FailureTest>::GetSetUpCaseOrSuite(char const*, int)' from > file 'obj/third_party/googletest/gtest/gtest.o' to global weak symbol > 'testing::Test::SetUpTestSuite()' from file > 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o' > means the weak symbol cannot be overridden at runtime. This was likely > caused by different translation units being compiled with different > visibility settings. > ld: warning: direct access in function > 'testing::internal::SuiteApiResolver<testing::internal::(anonymous > namespace)::FailureTest>::GetSetUpCaseOrSuite(char const*, int)' from > file 'obj/third_party/googletest/gtest/gtest.o' to global weak symbol > 'testing::Test::SetUpTestCase()' from file > 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o' > means the weak symbol cannot be overridden at runtime. This was likely > caused by different translation units being compiled with different > visibility settings. > ld: warning: direct access in function > 'testing::internal::SuiteApiResolver<testing::internal::(anonymous > namespace)::FailureTest>::GetTearDownCaseOrSuite(char const*, int)' > from file 'obj/third_party/googletest/gtest/gtest.o' to global weak > symbol 'testing::Test::TearDownTestSuite()' from file > 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o' > means the weak symbol cannot be overridden at runtime. This was likely > caused by different translation units being compiled with different > visibility settings. > ld: warning: direct access in function > 'testing::internal::SuiteApiResolver<testing::internal::(anonymous > namespace)::FailureTest>::GetTearDownCaseOrSuite(char const*, int)' > from file 'obj/third_party/googletest/gtest/gtest.o' to global weak > symbol 'testing::Test::TearDownTestCase()' from file > 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o' > means the weak symbol cannot be overridden at runtime. This was likely > caused by different translation units being compiled with different > visibility settings. > ld: fatal warning(s) induced error (-fatal_warnings) > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Traceback (most recent call last): > File "../../build/toolchain/mac/linker_driver.py", line 287, in <module> > Main(sys.argv) > File "../../build/toolchain/mac/linker_driver.py", line 97, in Main > subprocess.check_call(compiler_driver_args, env=env) > File > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", > line 190, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command > '['../../third_party/llvm-build/Release+Asserts/bin/clang++', '-B', > > '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/', > '-Wl,-fatal_warnings', '-stdlib=libc++', '-arch', 'x86_64', '-Werror', > '-isysroot', > '../../../../../Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk', > '-mmacosx-version-min=10.10.0', '-Wl,-ObjC', > '-Wl,-rpath,@loader_path/.', '-Wl,-rpath,@loader_path/../../..', '-o', > './v8_cppgc_shared_unittests', > '-Wl,-filelist,./v8_cppgc_shared_unittests.rsp', > './libv8_cppgc_shared_for_testing.dylib', './libv8_libbase.dylib']' > returned non-zero exit status 1 > [1189/2682] ACTION > //:run_gen-regexp-s...-case(//build/toolchain/mac:clang_x64) > ninja: build stopped: subcommand failed. > > On 10/12/20, Cameron Caturria <surviving.deceptive.wo...@gmail.com> wrote: > > Sorry, I got one of those build args wrong, starting again. > > > > > > On 10/12/20, Cameron Caturria <surviving.deceptive.wo...@gmail.com> > wrote: > >> Hi, > >> > >> When I create a debug build with the following arguments: > >> is_debug = true > >> v8_optimized_debug = true > >> target_cpu = "x64" > >> use_goma = false > >> goma_dir = "None" > >> v8_enable_backtrace = true > >> v8_enable_disassembler = true > >> v8_enable_object_print = true > >> v8_enable_verify_heap = true > >> use_custom_libcxx=false > >> the libv8_libbase.a and libv8_libplatform.a files do not get generated. > >> In addition, I get the following warning on every target: > >> Bad dips log signature/ version, starting over. > >> I am using a screen reader and can't capture that output fast enough, > >> so I'm having to recite it from memory. Please forgive possible > >> inaccuracies. > >> Please advise, > >> > >> Cameron. > >> > >> > >> On 10/12/20, Cameron Caturria <surviving.deceptive.wo...@gmail.com> > >> wrote: > >>> Hi Jakob, > >>> Thank you very much for your advice. > >>> I should disclose to all of you that I am a blind user who relies on > >>> text to speech software to access my computer. The build output goes > >>> by and gets cleared away so fast that I completely miss the majority > >>> of it. > >>> Is there a tool or build output file I can reference to find out > >>> exactly which defines are required? > >>> While I'm waiting for the debug build to finish I tried various > >>> combinations of the flags you supplied, but I'm getting the same > >>> result. > >>> Thanks. > >>> > >>> > >>> On 10/12/20, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > >>>> On Mon, Oct 12, 2020 at 2:38 AM Cameron Caturria > >>>> <surviving.deceptive.wo...@gmail.com> wrote: > >>>>> > >>>>> Hi, > >>>>> I have been trying for some time to build a working V8 static library > >>>>> under Mac OS with limited success. I can get it to build, but the > >>>>> result is unstable. > >>>>> I have successfully setup depot-tools, added it to my $PATH, fetched > >>>>> V8 and checked out the desired version (I selected version 8.1.307, > >>>>> since this is the version that ships with the latest stable Node.js). > >>>>> If I use the one step build process after gclient sync: > >>>>> Tools/dev/gm.py x64.release > >>>>> The result is a build that doesn’t work at all (v8::V8::Initialize() > >>>>> never returns, program hangs). > >>>>> If I add use_custom_libcxx to build arguments as suggested by this > >>>>> related Stack Overflow question: > >>>>> > https://stackoverflow.com/questions/62250913/cross-compiling-v8-for-arm-hello-world-hangs-during-initialize > >>>>> I get a somewhat usable build with some stability issues. > >>>>> Specifically, it will crash inside of all error object constructors > >>>>> (v8::Exception::RangeError, v8::Exception::TypeError etc). > >>>>> The v8_shell sample application that builds alongside V8 works as it > >>>>> should, but if I build it myself it crashes after evaluating every > >>>>> line. > >>>>> I am new to V8, and the documentation is anything but beginner > >>>>> friendly. In addition to the embedding guide, I am mostly relying on > >>>>> the API reference made available by nodesource.com. > >>>>> I am using the following build args: > >>>>> > >>>>> is_component_build = false > >>>>> is_debug = false > >>>>> target_cpu = "x64" > >>>>> use_goma = false > >>>>> goma_dir = "None" > >>>>> v8_enable_backtrace = true > >>>>> v8_enable_disassembler = true > >>>>> v8_enable_object_print = true > >>>>> v8_enable_verify_heap = true > >>>>> use_custom_libcxx=false > >>>>> I am using the default Clang which ships with Xcode: > >>>>> > >>>>> Apple clang version 11.0.0 (clang-1100.0.33.12) > >>>>> Target: x86_64-apple-darwin19.6.0 > >>>>> Thread model: posix > >>>>> InstalledDir: > >>>>> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > >>>>> > >>>>> I am using the following compiler and linker flags to build the > >>>>> shell.cc example: > >>>>> g++ -O3 -std=c++0x ./shell.cc -I/usr/local/include/v8 -lwee8 > >>>>> -lv8_libbase -lv8_libplatform -pthreads -o v8_shell > >>>>> > >>>>> A nudge in the right direction would be greatly appreciated. > >>>>> Thanks in advance. > >>>> > >>>> There are a couple of preprocessor flags (the -DV8_OPTION_NAME flags > >>>> you see in the build output) that affect V8's ABI, notably > >>>> V8_COMPRESS_POINTERS and V8_31BIT_SMIS_ON_64BIT_ARCH, and perhaps > >>>> V8_ENABLE_CHECKS too. > >>>> > >>>> Compiling the shell should be done with the exact same flags as the V8 > >>>> build. > >>>> > >>>> -- > >>>> -- > >>>> v8-users mailing list > >>>> v8-users@googlegroups.com > >>>> http://groups.google.com/group/v8-users > >>>> --- > >>>> You received this message because you are subscribed to the Google > >>>> Groups > >>>> "v8-users" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an > >>>> email to v8-users+unsubscr...@googlegroups.com. > >>>> To view this discussion on the web visit > >>>> > https://groups.google.com/d/msgid/v8-users/CAHQurc_jNB%2BD%3Dnku7AMBNt9TX79_m2u-fq8HDkhxAbte658BXQ%40mail.gmail.com > . > >>>> > >>> > >> > > > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-users/CAKAqCuwPFtYPW2RcwdJwVWG80LaZt1WW-o-U85xvm1XvhJUPSg%40mail.gmail.com > . > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAH3p7oNDG4L2CkA03ojDWoYaOqPQh31qKPuu1C59bJcZrOn%2B0w%40mail.gmail.com.
