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.
