Appetite for Android & iOS Support? #1640
Comments
|
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. |
|
I managed to build rusty_v8 for iOS by following the steps below.
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());
}
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
|
|
@lazytiger awesome to hear this is achievable with minimal patches. I'm unable to get past |
Sorry to hear that. I didn't encounter that problem.
|
|
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? 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: And the versions: |
|
Initially I tried to build iOS with [email protected] but also tried with latest. My last attempt was with the following; CommandV8_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
|
If you have issues with the header search paths or sysroot, I suggest you placing in the gn_out dir ( |
|
Ok well I now appear to have an iOS build... Needed to add the |
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 |
|
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 Now:
Please ping me if you get it work on iOS :) |
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 |
|
@leanmendoza I only use rusty_v8 without deno and it works fine on iOS. rusty_v8 version is 129.0.0 |
The `ffi` ext is difficult to cross compile (see denoland/rusty_v8#1640)
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
}
} |
|
As I said at #1595, the cause of I had tried modifying the 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 |
|
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:6I 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 don't have a Linux box running at the moment so was trying in Docker. I ran into: The command is running with sysroot: Which doesn't make sense to me since I expected the sysroot to be: I've tried modifying |
What I did to solve this is manually copying the |
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. Has anyone built and run 130.0.1 successfully? |
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 [email protected] 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 [email protected] 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
[email protected](compatible with [email protected]) works without any modifications on Android.Deno Runtime
deno_runtime@5c54dc5(compatible with[email protected]) 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_cachesymbol is referenced indirectly viaop_ffi_unsafe_callback_create->libffi::middle::Closure::new->low::prep_closure->raw::ffi_prep_closure_loc->__builtin___clear_cachehence 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_cacheissue. 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_cacheruntime error in the FFI feature. You need to specify the compiler-rt runtime libraries usingcargo::rustc-link-search=...andcargo::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_writeto preventconsole.logfrom entering the void. I was thinking it would be good to add support for thelogcrate as an option forStdio. As then logs can be directly sent to__android_log_writeor 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 [email protected] compiled for iOS.
I've followed the cross-compiling for iOS guide and updated the
build.rsscript to include the keys recommended for iOS. I've had to stray from the recommendations by omittingv8_enable_i18n_support = false(seems its required forsrc/icu.rs) and addedv8_enable_shared_ro_heap = truedue tov8_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 [email protected] 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.rsscript to include the keys recommended for iOS. I've had to stray from the recommendations by omittingv8_enable_i18n_support = false(seems its required forsrc/icu.rs) and addedv8_enable_shared_ro_heap = truedue tov8_enable_pointer_compression = false. For some reason I have had to include-isysrootflag 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 forkingdenoland/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_PATHis missing. This is because [email protected] 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 [email protected].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.The text was updated successfully, but these errors were encountered: