Unable to compile V8 9.9 for Android with use_custom_libcxx = false

Viewed 451

I'm trying to update our V8 integration for Android from 9.1 to 9.9 and I'm unable to build 9.9 with the default NDK standard library (use_custom_libcxx = false).

Using Ubuntu 20.04 LTS 64-bit, I'm trying to build V8 9.9 with the following options:

target_os="android"
is_debug=true
target_cpu="x86"
is_component_build=false
v8_static_library=true
v8_monolithic=true
v8_enable_i18n_support=false
v8_use_external_startup_data=false
use_custom_libcxx=false

Build output is:

 ninja -C out/Android_Debug_x86 ninja: Entering directory
 `out/Android_Debug_x86' [385/3327] LINK
 clang_x86/bytecode_builtins_list_generator FAILED:
 clang_x86/bytecode_builtins_list_generator  python3
 "../../build/toolchain/gcc_link_wrapper.py"
 --output="clang_x86/bytecode_builtins_list_generator" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -pie
 -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -m32 -no-canonical-prefixes -Werror -rdynamic --sysroot=../../build/linux/debian_sid_i386-sysroot -Wl,-z,defs -Wl,--as-needed -pie -Wl,--disable-new-dtags -Wl,-O2 -Wl,--gc-sections -o "clang_x86/bytecode_builtins_list_generator" -Wl,--start-group @"clang_x86/bytecode_builtins_list_generator.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt ld.lld: error: ../../build/linux/debian_sid_i386-sysroot/usr/lib/gcc/i686-linux-gnu/10/libstdc++.so:
 undefined reference to __divmoddi4@GCC_7.0.0
 [--no-allow-shlib-undefined] clang++: error: linker command failed
 with exit code 1 (use -v to see invocation) [390/3327] CXX
 clang_x86/obj/torque_base/implementation-visitor.o ninja: build
 stopped: subcommand failed.

I'm able to build V8 9.9 with use_custom_libcxx=true, but this will lead to conflicting standard libraries when trying to build the project that is later interfacing with V8. (Which is using the Android NDK with CMake and the standard libraries delivered with that respectively.)

Is there anything I can change to successfully build V8 9.9 without the custom standard library?

If the custom standard library is now mandatory, what would be the least difficult way to handle this? The API of V8 references standard library classes without customizable namespaces, so I assume I would have to build my own API around it, decoupled from either standard library, and put it all into a shared library.

In any case, I would definitely prefer getting the build with use_custom_libcxx=false going again since this method of embedding is a lot more convenient.

Edit: Since we are only using x86 for the emulator and would be able to skip it, I also attempted to build ARM/ARM64 (Debug & Release) on 9.9 and x86/ARM/ARM64 on 9.8 using the same build flags. They are also failing, but with different errors:

arm64 on 9.8

ninja -C out/Android_Debug_arm64
ninja: Entering directory `out/Android_Debug_arm64'
[399/3459] LINK ./torque-language-server
FAILED: torque-language-server exe.unstripped/torque-language-server 
python3 "../../build/toolchain/gcc_link_wrapper.py" --output="./torque-language-server" --strip="../../third_party/llvm-build/Release+Asserts/bin/llvm-strip" --unstripped-file="./exe.unstripped/torque-language-server" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,max-page-size=4096 -Wl,--color-diagnostics -Wl,--no-rosegment -Wl,--no-call-graph-profile-sort -Wl,--exclude-libs=libvpx_assembly_arm.a --unwindlib=none --target=aarch64-linux-android23 -Wl,-mllvm,-enable-machine-outliner=never -no-canonical-prefixes -Werror --sysroot=../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot -Wl,--warn-shared-textrel -Wl,-z,defs -Wl,--as-needed -pie -Bdynamic -Wl,-z,nocopyreloc -Wl,--warn-shared-textrel -Wl,-O2 -Wl,--gc-sections -o "./exe.unstripped/torque-language-server" -Wl,--start-group @"./torque-language-server.rsp"  -Wl,--end-group  -ldl -lm -llog
ld.lld: error: undefined symbol: _Unwind_Resume
>>> referenced by torque-language-server.cc:0 (../../src/torque/ls/torque-language-server.cc:0)
>>>               obj/torque-language-server/torque-language-server.o:(v8::internal::torque::ls::WrappedMain(int, char const**))
>>> referenced by contextual.h:0 (../../src/torque/contextual.h:0)
>>>               obj/torque-language-server/torque-language-server.o:(v8::internal::torque::ls::WrappedMain(int, char const**))
>>> referenced by fstream:0 (../../third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:0)
>>>               obj/torque-language-server/torque-language-server.o:(v8::internal::torque::ls::WrappedMain(int, char const**))
>>> referenced 2144 more times
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
[416/3459] CXX clang_x64_v8_arm64/obj/torque_base/implementation-visitor.o
ninja: build stopped: subcommand failed.

arm 9.8

ninja -C out/Android_Debug_arm
ninja: Entering directory `out/Android_Debug_arm'
[3101/3433] ACTION //:run_mksnapshot_default(//build/toolchain/android:android_clang_arm)
FAILED: gen/embedded.S gen/snapshot.cc 
python3 ../../tools/run.py ./clang_x86_v8_arm/mksnapshot --turbo_instruction_scheduling --target_os=android --target_arch=arm --embedded_src gen/embedded.S --embedded_variant Default --random-seed 314159265 --startup_src gen/snapshot.cc --native-code-counters --verify-heap
./clang_x86_v8_arm/mksnapshot: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
Return code is 127

A summary of my current situation, debug and release both produce the same outcome:

9.9 x86: divmod undefined
9.9 arm: divmod undefined
9.9 arm64: _Unwind_Resume undefined

9.8 x86: _Unwind_Resume undefined
9.8 arm: libatomic.so.1 missing
9.8 arm64: _Unwind_Resume undefined

9.1 is still building when I switch back to it.

1 Answers

Seems like you're hitting this bug: crbug.com/v8/12673

So as that bug describes, one possible workaround is to use an older sysroot for the time being, e.g. the one used in V8 9.8.

Another possible workaround is to turn off sysroot usage by adding use_sysroot = false to your GN args (and you'll likely need treat_warnings_as_errors = false too then). That will use your system's libraries instead. Note that usually that's a liability: it means that when your system changes, that can affect your builds. So I wouldn't recommend that as a long-term solution. But it should avoid the problem until the bundled sysroot is fixed.

(FWIW this is unrelated to compiling for Android, as it seems to affect regular Linux ia32 builds as well. Android + ia32 is a rare combination, but I assume that you know what you're doing there.)

Related