Rust not compatible with ndk r23

[Zackptg5]

NDK r23 removed libgcc which rust still uses. Work on switching it over is in progress but still not yet completed. See here for more details.

Keeping this open until fixed to keep track of it, will continue to use r21e until then

This keeps track of NDK compatibility in rust

Binaries/packages affected:
Exa
Quiche

[ar37-rs]

@Zackptg5 may it helps: https://github.com/Ar37-rs/ndk-r23-fix-for-rust

[Zackptg5]

@Zackptg5 may it helps: https://github.com/Ar37-rs/ndk-r23-fix-for-rust

Although that may be a temporary fix, mixing and matching files from different ndk versions could lead to trouble. I'll wait until there's an official fix on the rust end of things which looks like they're getting close

[MarijnS95]

@Zackptg5 Fwiw we've "fixed" rust-mobile/ndk#149 through rust-mobile/ndk#189 so that you can use r23 together with cargo-apk and friends. Indeed, I can only recommend against copying random binaries, even if you take them from an official NDK build yourself.

[Zackptg5]

@Zackptg5 Fwiw we've "fixed" rust-windowing/android-ndk-rs#149 through rust-windowing/android-ndk-rs#189 so that you can use r23 together with cargo-apk and friends. Indeed, I can only recommend against copying random binaries, even if you take them from an official NDK build yourself.

Does this require nightly builds? I tried
cargo +nightly rustc --release --target $target_host -j $jobs
with same variable args as before and still get the lgcc error.

I've been using cargo-ndk package at this point with:
cargo ndk -t $barch -p $lapi -- build --release

Using nightly with -Zbuild-std works as previously discussed by others in the issues

I'm not building apks but binaries such as quiche

[MarijnS95]

@Zackptg5 You can (ab)use cargo apk with cargo apk check to build just the binary but not an APK - cargo-ndk doesn't have this workaround/fix. The goal is to reuse our ndk-build crate (where most/all of this magic happens) in cargo-ndk as well but I'm not willing to implement that unless we can migrate this tool into the android-ndk-rs repo for smooth management (perhaps we should just create and release this tool under a separate name, but that's a discussion for another time).

In other words, this is a workaround specifically provided by ndk-build/cargo-apk, and will not work when rustc is invoked na(t)ively nor cargo-ndk is used.

[Zackptg5]

@MarijnS95
Ok, so I tried this:
cargo apk check --release --target $target_host -j $jobs --features ffi,pkg-config-meta,qlog

And although it finished without errors, there's no lib present

Read through the various issues some more and the termux method works well for my use case. Is SDK a requirement for cargo-apk even though I'm not actually building an apk? It errored out until I set sdk root path

[MarijnS95]

@Zackptg5 That's strange, it's how I have understood rust-mobile/ndk#151 (comment). Maybe crate-type = ["cdylib"] still needs to be set or something like that, perhaps this trick doesn't work anymore :(

even though I'm not actually building an apk

As said this is a hack that leverages cargo-apk infrastructure, tricking it to almost build the apk.

[Zackptg5]

@MarijnS95
That's already set in the toml
No libs are built at all either. In the case of quiche here, I'm just looking for some libs

[Zackptg5]

Will use the termux workaround for now: d63f9fb

(I'm happy to keep testing cargo apk method)