Getting unstable builds of V8 under Mac OS

[Cameron Caturria]

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.

[Jakob Gruber]

On Mon, Oct 12, 2020 at 2:38 AM Cameron Caturria <surviving.de...@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).

We'll need more information. Please compile a debug build

is_debug = true
v8_optimized_debug = false

 

and paste the output. A backtrace would also help. What are the target/host platforms? Please also use the latest version / current git master.

--
--
v8-users mailing list
v8-u...@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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKAqCuw0ypWySMq6N4snKj9b6Zvygp_eVQ4T2EZ3BQyRp1oy8A%40mail.gmail.com.

[Ben Noordhuis]

On Mon, Oct 12, 2020 at 2:38 AM Cameron Caturria
<surviving.de...@gmail.com> wrote:
>

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.

[Cameron Caturria]

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.

> --
> --
> v8-users mailing list
> v8-u...@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+u...@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.
>

[Cameron Caturria]

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.

[Cameron Caturria]

Sorry, I got one of those build args wrong, starting again.

[Cameron Caturria]

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.

[Jakob Gruber]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKAqCuwPFtYPW2RcwdJwVWG80LaZt1WW-o-U85xvm1XvhJUPSg%40mail.gmail.com.