Appetite for Android & iOS Support?

Question

Appetite for Android & iOS Support?

Opened this issue a month ago · 19 comments

Introduction

I would like to understand the appetite and work required to get Android and iOS support from Rusty V8. I know Android builds have previously been a included as a feature of Rusty V8, but were sadly short-lived. To my knowledge iOS builds have been attempted by community members but no support has landed in Rusty V8. I have a proof-of-concept of Deno Runtime interacting with a WebView on Android, but before I go much further with this wanted to see if there was any motivation to land support for pre-built Android & iOS binaries. If there is no motivation for this feature I can alternatively start exploring NativeScript, however, I believe Rusty V8 is a better solution due to Deno Core & Deno Runtime.

The current state of Deno on mobile (as I understand it)

Important

I am updating this section as progress occurs and as people provide additional information.

I've been whittling away at a prototype over the last few months and I've collated the knowledge I have gained from my attempts getting Deno running on Android & iOS. I know others have also been making attempts in this department and welcome people to chime in, as seen by the revert commits that reference disable Android in ci.

Android

Rusty V8

I have had success with getting rusty_v8@0.101.0 working on Android, however you need to cherry-pick the patch to disable relative vtable on Android.

For anyone following along at home, you can find the rusty_v8@0.101.0 binaries for Android on my fork or use RUSTY_V8_MIRROR=https://github.com/aidant/rusty_v8/releases/download (no promises for support).

I and others have been making attempts to build latest for Android and are encountering fatal error: 'features.h' file not found. I'm not sure if it also applies to this issue, but I saw it stated that clang downloaded from chromium does not include libclang shared libraries. @devsnek if your discussions with Chromium team are public could you please provide the tracking issue?

Deno Core

deno_core@0.301.0 (compatible with rusty_v8@0.101.0) works without any modifications on Android.

Deno Runtime

deno_runtime@5c54dc5 (compatible with deno_core@0.301.0) works on Android when combined with a cherry-pick of allowing webgpu to build on unsupported platforms and the removal of the FFI feature.

outdated FFI __clear_cache issue

Without removing the FFI feature, the application errors at runtime with dlopen failed: cannot locate symbol "__clear_cache". Decompiling the binary I can see the __clear_cache symbol is referenced indirectly via op_ffi_unsafe_callback_create -> libffi::middle::Closure::new -> low::prep_closure -> raw::ffi_prep_closure_loc -> __builtin___clear_cache hence the removal of the FFI feature.

I am not experienced enough with this ecosystem to understand what is needed to fix the root cause of the __clear_cache issue. If anyone has any pointers that would be appreciated. Otherwise if I get some free time I intend to look into this myself at some point.

I believe I have identified the fix for the __clear_cache runtime error in the FFI feature. You need to specify the compiler-rt runtime libraries using cargo::rustc-link-search=... and cargo::rustc-link-lib=static=clang_rt.builtins-{target_arch}-{target_os}. You can see my work-in-progress commit which I'll turn into a PR once its ready.

A side note, I've had to pipe stdout and stderr to __android_log_write to prevent console.log from entering the void. I was thinking it would be good to add support for the log crate as an option for Stdio. As then logs can be directly sent to __android_log_write or the equivalent on iOS. This is a feature I could probably open a PR for.

iOS

Rusty V8

outdated iOS attempts

So far I have been unsuccessful in getting rusty_v8@0.101.0 compiled for iOS.

I've followed the cross-compiling for iOS guide and updated the build.rs script to include the keys recommended for iOS. I've had to stray from the recommendations by omitting v8_enable_i18n_support = false (seems its required for src/icu.rs) and added v8_enable_shared_ro_heap = true due to v8_enable_pointer_compression = false. I've also had to apply the patch to remove support for bitcode.

I'm currently running into fatal error: 'cstdint' file not found. I suspect the cause is clang downloaded from chromium does not include libclang shared libraries but am out of my depth with my current knowledge.

I've been able to get rusty_v8@0.101.0 to compile for iOS, but I have been unable to test it yet due to issues in Deno Runtime described bellow.

I've followed the cross-compiling for iOS guide and updated the build.rs script to include the keys recommended for iOS. I've had to stray from the recommendations by omitting v8_enable_i18n_support = false (seems its required for src/icu.rs) and added v8_enable_shared_ro_heap = true due to v8_enable_pointer_compression = false. For some reason I have had to include -isysroot flag to the bindgen clang args, while others have not. I've also had to apply the patch to remove support for bitcode and to not rely on external modules for version parsing which involves forking denoland/chromium_build. Note I do not think these patches are required for latest.

There is also an issue where the file for RUSTY_V8_SRC_BINDING_PATH is missing. This is because rusty_v8@0.101.0 does not build for iOS normally and therefore, the gen folder does not include the bindings file for iOS. Latest Rusty V8 includes a patch which respects explicitly set RUSTY_V8_SRC_BINDING_PATH but this is not included in rusty_v8@0.101.0.

Deno Core

N/A

Deno Runtime

I've not been able to get Deno Runtime working on iOS yet, a bunch of the extensions don't compile for iOS without patches, I'll see if I can tackle this at some point.

From my understanding (please correct me if I am wrong), the FFI feature will also need to be disabled on iOS ~~due to Apple requiring statically linked libraries~~. Edit, you can use dynamic modules, but you have to embed them in your app’s binary. However, due to Turbocall the FFI feature will not work as is due to absence of writable executable memory in iOS apps.

Answer 1 · 2024-10-13T10:08:34.000Z

I've been experimenting with Deno (via the deno_runtime crate) this past week and had easy success on desktop platforms, but for mobile I also faced this problem of rusty_v8 lacking support for iOS and no longer shipping Android prebuilt shared libraries, which I had trouble cross compiling on my end (I was trying latest rusty_v8 and also faced the missing features.h problem).

Even though I don't know that much about Deno I work hard and found out about some fixes myself such as denoland/deno#575 (comment) that might also apply to iOS. If there's anything I can do to help get this issue resolved, I'd love to chime in. I think this would be huge for Deno to run on even more platforms.

Answer 2 · 2024-10-16T09:16:29.000Z

I managed to build rusty_v8 for iOS by following the steps below.

modify build.rs adding support for ios

if target_triple != env::var("HOST").unwrap() && target_os == "ios" {
    let arch = if target_arch == "x86_64" {
      "x64"
    } else if target_arch == "aarch64" {
      "arm64"
    } else {
      "unknown"
    };
    gn_args.push(format!(r#"v8_target_cpu="{}""#, arch).to_string());
    gn_args.push(format!(r#"target_cpu="{}""#, arch).to_string());
    gn_args.push(r#"target_os="ios""#.to_string());
    gn_args.push(format!(r#"isa="{}""#, arch).to_string());
    gn_args.push("treat_warnings_as_errors=false".to_string());
    gn_args.push("use_sysroot=true".to_string());
    gn_args.push("v8_enable_webassembly=false".to_string());
    gn_args.push("ios_enable_code_signing=false".to_string());
  }

run build from the following script to make sure all source code build for iOS

export V8_FROM_SOURCE=1
ARCH=arm64
SDK=iphoneos
SYSROOT=`xcrun --sdk $SDK --show-sdk-path`
export CFLAGS="-isysroot $SYSROOT -arch $ARCH -fobjc-arc -fobjc-legacy-arc -mios-version=10.0"
export LDFLAGS="-isysroot $SYSROOT -arch $ARCH"
cargo build --profile release --target aarch64-apple-ios

I also encounter some missing .pydeps problem, just download the missing ones to pass.

Answer 3 · 2024-10-16T22:07:06.000Z

@lazytiger awesome to hear this is achievable with minimal patches. I'm unable to get past fatal error: 'cstdint' file not found, I for sure thought the sysroot environment variables would be the missing pieces to progress past this error, but alas no luck. Did you encounter it? Are you able to share some info on your build environment and or a repository?

Answer 4 · 2024-10-18T03:14:30.000Z

@lazytiger awesome to hear this is achievable with minimal patches. I'm unable to get past fatal error: 'cstdint' file not found, I for sure thought the sysroot environment variables would be the missing pieces to progress past this error, but alas no luck. Did you encounter it? Are you able to share some info on your build environment and or a repository?

Sorry to hear that. I didn't encounter that problem.
My system is arm64, maybe that's the problem.

Darwin macdeMac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64

Answer 5 · 2024-10-18T11:52:21.000Z

I was able to build it and test it several times (changing params to see if it worked). Could you specify the versions you are using?
With git log --oneline -1 and git submodule status in the rusty_v8 repo folder should be enough :)

I also tested what @lazytiger posted, and the build passed as well.

In our case, what we're struggling with is the following crash when we try to initialize the v8:

#
# Fatal process out of memory: Oilpan: CagedHeap reservation.
#
==== C stack trace ===============================

    0   test-v8-deno-v2                     0x0000000102ae00b8 v8::base::debug::StackTrace::StackTrace() + 24
    1   test-v8-deno-v2                     0x0000000102ae7208 v8::platform::(anonymous namespace)::PrintStackTrace() + 24
    2   test-v8-deno-v2                     0x0000000102ad39e8 v8::base::FatalOOM(v8::base::OOMType, char const*) + 68
    3   test-v8-deno-v2                     0x0000000102aeefd4 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) + 112
    4   test-v8-deno-v2                     0x0000000102c82968 v8::internal::CppHeap::CppHeap(v8::Platform*, std::__1::vector<std::__1::unique_ptr<cppgc::CustomSpaceBase, std::__1::default_delete<cppgc::CustomSpaceBase>>, std::__1::allocator<std::__1::unique_ptr<cppgc::CustomSpaceBase, std::__1::default_delete<cppgc::CustomSpaceBase>>>> const&, cppgc::Heap::MarkingType, cppgc::Heap::SweepingType) + 0
    5   test-v8-deno-v2                     0x000000010317a8b0 cppgc::internal::FatalOutOfMemoryHandler::operator()(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, v8::SourceLocation const&) const + 48
    6   test-v8-deno-v2                     0x0000000103184930 cppgc::internal::CagedHeap::CagedHeap(v8::PageAllocator&, unsigned long) + 0
    7   test-v8-deno-v2                     0x00000001031846c4 cppgc::internal::CagedHeap::InitializeIfNeeded(v8::PageAllocator&, unsigned long) + 92
    8   test-v8-deno-v2                     0x000000010317a9bc cppgc::InitializeProcess(v8::PageAllocator*, unsigned long) + 84
    9   test-v8-deno-v2                     0x0000000102aa8008 v8::cppgc::initalize_process::hc76e686999b4cdfb + 64
    10  test-v8-deno-v2                     0x0000000102372f64 deno_core::runtime::setup::v8_init::h89404fbfcc2c78a7 + 2924
    11  test-v8-deno-v2                     0x000000010237323c _ZN9deno_core7runtime5setup7init_v828_$u7b$$u7b$closure$u7d$$u7d$17hac0aa050ceda9e77E + 64
    12  test-v8-deno-v2                     0x00000001026619ec _ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17h8e0e09e4ad9604f1E + 132
    13  test-v8-deno-v2                     0x00000001035de9b8 std::sys::sync::once::queue::Once::call::h118eb67701f86caa + 764
    14  test-v8-deno-v2                     0x0000000102661904 std::sync::once::Once::call_once::hf905030a9631621d + 232
    15  test-v8-deno-v2                     0x00000001023730d4 deno_core::runtime::setup::init_v8::h1b3f58cd3b55cc0e + 212
    16  test-v8-deno-v2                     0x00000001025a1688 deno_core::runtime::jsruntime::JsRuntime::try_new::h28c266490204cb89 + 180
    17  test-v8-deno-v2                     0x00000001025a14ec deno_core::runtime::jsruntime::JsRuntime::new::hca16624ab035b0bf + 36
    18  test-v8-deno-v2                     0x00000001022aef40 v8testdeno::js::create_runtime::h75e96197e2a9334c + 2016
    19  test-v8-deno-v2                     0x00000001022af310 v8testdeno::js::scene_thread::he4a0be15c7226f40 + 372
    20  test-v8-deno-v2                     0x00000001022c7d98 _ZN10v8testdeno18rust_thread_create28_$u7b$$u7b$closure$u7d$$u7d$17h66f1e822a4f735a2E + 36
    21  test-v8-deno-v2                     0x0000000102295318 std::sys::backtrace::__rust_begin_short_backtrace::h36300e6653516db0 + 28
    22  test-v8-deno-v2                     0x00000001022cfb40 _ZN3std6thread7Builder16spawn_unchecked_28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17ha4c42f5db08d7cf6E + 28
    23  test-v8-deno-v2                     0x00000001022cce88 _ZN115_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$9call_once17hc961099b7bd1a368E + 28
    24  test-v8-deno-v2                     0x0000000102294488 std::panicking::try::do_call::h052a2c1b617925ec + 68
    25  test-v8-deno-v2                     0x00000001022cfd1c __rust_try + 32
    26  test-v8-deno-v2                     0x00000001022cf9b8 _ZN3std6thread7Builder16spawn_unchecked_28_$u7b$$u7b$closure$u7d$$u7d$17he620b80070063611E + 380
    27  test-v8-deno-v2                     0x00000001022d83a4 _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h1262b14a31958ce8E + 24
    28  test-v8-deno-v2                     0x00000001035dc0dc std::sys::pal::unix::thread::Thread::new::thread_start::h92272ca226fb516f + 36
    29  libsystem_pthread.dylib             0x00000001f94cd06c _pthread_start + 136
    30  libsystem_pthread.dylib             0x00000001f94c80d8 thread_start + 8

And the versions:

 rusty_v8 v0.105.1
 c6d44e625aa64fa89cbdc971dfd301353bee04f3 build (remotes/origin/20240819)
 60a590902cf146c282f15242401bd8543256e2a2 buildtools (60a5909)
 ed3733b91e472a1e7a641c1f0c1e6c0ea698e958 third_party/abseil-cpp (ed3733b9)
 0a92994d729ff76a58f692d3028ca1b64b145d91 third_party/fp16/src (0a92994)
 a22a8f24224ddda8b856437d7e8560de1da3f8e1 third_party/icu (remotes/origin/20230808_rustyv8)
 2f6f2ff5e4c1d727377f5e1b9e1903d871f41e74 third_party/jinja2 (heads/main)
 f801c947082a3e0a4b48780303526b73905f6ecd third_party/libc++/src (remotes/origin/master-5055-gf801c9470)
 eb6567388e89d9730c76dee71d68ac82e4a1abf6 third_party/libc++abi/src (remotes/origin/master-411-geb65673)
 116c20dae60d84a77005697cf29f72783f81b0f9 third_party/libunwind/src (remotes/origin/master-304-g116c20d)
 6638e9b0a79afc2ff7edd9e84b518fe7d5d5fea9 third_party/markupsafe (heads/main)
 63b7be17f8981d716ea9a0d65bb04654d79548a8 tools/clang (63b7be17)
 c436e92f6c7cdd25690d3b33477747f51b6d5f3e v8 (12.9.202.9-denoland-c436e92f6c7cdd25690d)

Answer 6 · 2024-10-18T12:19:08.000Z

Initially I tried to build iOS with rusty_v8@0.101.0 but also tried with latest. My last attempt was with the following;

Command

V8_FROM_SOURCE=1 \
PYTHON=python3 \
RUST_BACKTRACE=full \
ARCH=arm64 \
SDK=iphoneos \
SYSROOT=$(xcrun --sdk $SDK --show-sdk-path) \ # Xcode v15.4.0 & iOS SDK v17.5
CFLAGS="-isysroot $SYSROOT -arch $ARCH -fobjc-arc -fobjc-legacy-arc -mios-version=13.0" \
LDFLAGS="-isysroot $SYSROOT -arch $ARCH" \
cargo build -vv --release --target aarch64-apple-ios

`git log --oneline -1`

a076d03 Update bindgen to fix builds with LLVM 19.1 (#1639)

`git submodule status`

c6d44e625aa64fa89cbdc971dfd301353bee04f3 build (remotes/origin/20240819)
60a590902cf146c282f15242401bd8543256e2a2 buildtools (60a5909)
ed3733b91e472a1e7a641c1f0c1e6c0ea698e958 third_party/abseil-cpp (ed3733b9)
0a92994d729ff76a58f692d3028ca1b64b145d91 third_party/fp16/src (0a92994)
a22a8f24224ddda8b856437d7e8560de1da3f8e1 third_party/icu (remotes/origin/20230808_rustyv8)
2f6f2ff5e4c1d727377f5e1b9e1903d871f41e74 third_party/jinja2 (heads/main)
f801c947082a3e0a4b48780303526b73905f6ecd third_party/libc++/src (remotes/origin/master-5055-gf801c9470)
eb6567388e89d9730c76dee71d68ac82e4a1abf6 third_party/libc++abi/src (remotes/origin/master-411-geb65673)
116c20dae60d84a77005697cf29f72783f81b0f9 third_party/libunwind/src (remotes/origin/master-304-g116c20d)
6638e9b0a79afc2ff7edd9e84b518fe7d5d5fea9 third_party/markupsafe (heads/main)
63b7be17f8981d716ea9a0d65bb04654d79548a8 tools/clang (63b7be17)
d5e5d10dc91365077bad1ea2303c5e59ebb85ddb v8 (12.9.202.18-denoland-d5e5d10dc91365077bad)

`git diff`

diff --git a/build.rs b/build.rs
index 4aead47..90375df 100644
--- a/build.rs
+++ b/build.rs
@@ -308,6 +308,24 @@ fn build_v8(is_asan: bool) {
    );
  }

+  if target_triple != env::var("HOST").unwrap() && target_os == "ios" {
+    let arch = if target_arch == "x86_64" {
+      "x64"
+    } else if target_arch == "aarch64" {
+      "arm64"
+    } else {
+      "unknown"
+    };
+    gn_args.push(format!(r#"v8_target_cpu="{}""#, arch).to_string());
+    gn_args.push(format!(r#"target_cpu="{}""#, arch).to_string());
+    gn_args.push(r#"target_os="ios""#.to_string());
+    gn_args.push(format!(r#"isa="{}""#, arch).to_string());
+    gn_args.push("treat_warnings_as_errors=false".to_string());
+    gn_args.push("use_sysroot=true".to_string());
+    gn_args.push("v8_enable_webassembly=false".to_string());
+    gn_args.push("ios_enable_code_signing=false".to_string());
+  }
+
  if target_triple.starts_with("i686-") {
    gn_args.push(r#"target_cpu="x86""#.to_string());
  }

`uname -mor`

Darwin 23.6.0 arm64

I feel like there is some environment setup that I am missing, possibly Xcode related...

Answer 7 · 2024-10-18T12:26:48.000Z

I feel like there is some environment setup that I am missing, possibly Xcode related...

If you have issues with the header search paths or sysroot, I suggest you placing in the gn_out dir (target/aarch64-apple-ios/release/gn_out), copy the clang command that is failing and then trying to manually modifying, with that, you'll realized what is going wrong quicker. I had a similar issue for Android, but for iOS was well the first try. Copy the clang command here if you're still struggling

Answer 8 · 2024-10-18T13:01:14.000Z

Ok well I now appear to have an iOS build... Needed to add the -isysroot/... flag to the bindings clang args. Thanks for the pointers, will continue experiment with this to see if I can get Deno working on iOS too.

Answer 9 · 2024-10-21T17:14:41.000Z

From my understanding (please correct me if I am wrong), the FFI feature will also need to be disabled on iOS ~~due to Apple requiring statically linked libraries~~. Edit, you can use dynamic modules, but you have to embed them in your app’s binary. However, due to Turbocall the FFI feature will not work as is due to absence of writable executable memory in iOS apps.

On this last point, is there anyway we could utilize jitless mode here to get around this? https://v8.dev/blog/jitless. Not sure if this helps, just want to see if there's anyway I can help get this moving, this work is great and it'd be really good to see if we can get Deno working for both (relatively) seamlessly

Answer 10 · 2024-10-21T22:00:06.000Z

Does it work for you on iOS ? @lazytiger

@callum-gander AFAIK the iOS v8 build is always using jitless due to the limitations since 2020

I had got it worked with rusty_v8 = "0.74.3" and deno_core = "0.197". Both Android and iOS used to work just fine but we needed to bump some libraries and now we're trying to get working rusty_v8 = "0.105.1" and deno_core = "0.307.1".

Now:

Android works fine, but I needed to copy the android_toolchain from the v8 with depot_tools some maybe_clone_repo missing.
iOS, the build goes well and then it crashes when try to allocate the pages (with mmap).

Please ping me if you get it work on iOS :)

Answer 11 · 2024-10-22T07:28:20.000Z

On this last point, is there anyway we could utilize jitless mode here to get around this?

The jitless flag is what allows v8 to run on iOS and is already enabled. Additionally I believe an equivalent feature would be needed for Deno's FFI on iOS. This is because Deno dynamically generates optimized bindings (aka JIT) for FFI calls based on the type information provided from Deno.dlopen. This is what makes the FFI feature blazingly fast. This optimized binding generation happens outside of v8 in Deno through the use of the dynasmrt crate. Initially disabling the feature would be sufficient for a prototype, but long term this feature would be powerful.

Answer 12 · 2024-10-22T08:30:54.000Z

@leanmendoza I only use rusty_v8 without deno and it works fine on iOS. rusty_v8 version is 129.0.0

Answer 13 · 2024-10-24T12:10:49.000Z

@leanmendoza I only use rusty_v8 without deno and it works fine on iOS. rusty_v8 version is 129.0.0

have you made your own async runtime? would you mind to share how do you initialize the platform and runtime?

Answer 14 · 2024-10-25T01:21:50.000Z

@leanmendoza I only use rusty_v8 without deno and it works fine on iOS. rusty_v8 version is 129.0.0

have you made your own async runtime? would you mind to share how do you initialize the platform and runtime?

My usage is simple and typical. I register some C functions into v8, and all the async features are implemented in pure JS using Promise. The initialization code is typical, just copied from the Rusty_v8 docs with little modifications.

pub struct V8Engine {
    isolate: OwnedIsolate,
    isolate_scope: Option<HandleScope<'static, ()>>,
    handle_scope: Option<ContextScope<'static, HandleScope<'static>>>,
}

static mut V8_ENGINE: MaybeUninit<V8Engine> = MaybeUninit::uninit();

fn engine_mut() -> &'static mut V8Engine {
    unsafe { V8_ENGINE.assume_init_mut() }
}

fn main() {
    setup_logger().unwrap();
    v8::V8::set_flags_from_string(
        "--jitless",
    );
    let platform = v8::new_default_platform(0, false).make_shared();
    v8::V8::initialize_platform(platform);
    v8::V8::initialize();
    let isolate = v8::Isolate::new(Default:default());
    unsafe {
        V8_ENGINE.write(V8Engine {
            isolate,
            isolate_scope: None,
            handle_scope: None,
        });
        let engine = engine_mut();
        let isolate = &mut engine.isolate;
        let isolate_scope = HandleScope::new(isolate);
        engine.isolate_scope.replace(isolate_scope);
        let isolate_scope = engine.isolate_scope.as_mut().unwrap();

        let context = Context::new(isolate_scope, Default::default());
        let handle_scope = ContextScope::new(isolate_scope, context);
        engine.handle_scope.replace(handle_scope);

        // do some register works
       // do business
    }
}

Answer 15 · 2024-10-26T17:27:34.000Z

@aidant

As I said at #1595, the cause of fatal error: 'features.h' file not found problem is that since v0.95.0, rusty_v8 merged a new feature #1507, the build_binding would use the system libclang. Therefore, when cross building rusty_v8, there may be a problem that the header file cannot be found.

I had tried modifying the build.rs to add isysroot param, adjust https://github.com/aidant/rusty_v8/blob/3731038dbc8474b633dd3b4f8c756df3e6118a87/build.rs#L154 param, but it didn't works.

I also want to know why. In my opinion, the key to solving the problem is to first prevent the build script from using the system clang.

If you have any progress, please @ me, thank you very much

Answer 16 · 2024-11-04T06:12:52.000Z

The building failed with version 130.0.0 on Android.

 v8/include/v8-internal.h:1433:28: error: missing 'typename' prior to dependent type name 'Iterator::iterator_concept'
  v8/include/v8-internal.h:1446:28: error: missing 'typename' prior to dependent type name 'std::iterator_traits<Iterator>::iterator_concept'
  thread 'main' panicked at /home/hoping/.cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-130.0.0/build.rs:162:6

I have checked the build.rs, it failed in bindgen. Has anyone built successfully with 130.0.0 on Android?

This maybe a bug for bindgen. Actually bindgen use the host clang but not ndk-clang. My original clang version is 10, and after I upgrade clang to 17, the error is fixed.

Answer 17 · 2024-11-04T21:07:18.000Z

I don't have a Linux box running at the moment so was trying in Docker. I ran into:

third_party/icu/source/common/unicode/platform.h:162:13: fatal error: 'android/api-level.h' file not found

The command is running with sysroot:

third_party/android_toolchain/ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot

Which doesn't make sense to me since I expected the sysroot to be:

third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android

I've tried modifying tools/clang/scripts/build.py:1284 but no luck.

Answer 18 · 2024-11-04T21:54:18.000Z

I don't have a Linux box running at the moment so was trying in Docker. I ran into:
third_party/icu/source/common/unicode/platform.h:162:13: fatal error: 'android/api-level.h' file not found
The command is running with sysroot:
third_party/android_toolchain/ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
Which doesn't make sense to me since I expected the sysroot to be:
third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android
I've tried modifying tools/clang/scripts/build.py:1284 but no luck.

What I did to solve this is manually copying the android_toolchain from the same v8 version (it's something it should have been included in the bump with a maybe_clone_repository but not sure what happened). So I clone the same v8 repo from the original chromium and then move that folder.

Answer 19 · 2024-11-05T06:45:09.000Z

The building failed with version 130.0.0 on Android.
 v8/include/v8-internal.h:1433:28: error: missing 'typename' prior to dependent type name 'Iterator::iterator_concept'
  v8/include/v8-internal.h:1446:28: error: missing 'typename' prior to dependent type name 'std::iterator_traits<Iterator>::iterator_concept'
  thread 'main' panicked at /home/hoping/.cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-130.0.0/build.rs:162:6
I have checked the build.rs, it failed in bindgen. Has anyone built successfully with 130.0.0 on Android?

This maybe a bug for bindgen. Actually bindgen use the host clang but not ndk-clang. My original clang version is 10, and after I upgrade clang to 17, the error is fixed

I managed to compile an Android build for version 130.0.1, but when I tried to use it, android did not recognize it as a legal dll.
I downgraded to 129.0.0 with the same build script and it worked fine.

Has anyone built and run 130.0.1 successfully?