Open b-spencer opened 4 years ago
Zazck
commented
4 years ago same issue encountered when trying to compile subparse on windows to x86_64-linux-android which depends on failure -> backtrace -> backtrace-sys -> cc
I'm using ~/.cargo/config but it seems no help at all.
after setting envvar, it compiles ok.
togetherwithasteria
commented
2 years ago Hiii! I now get this when trying the workaround from @b-spencer.
= note: ld: error: unable to find library -lgcc
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)Seems someone wants to add libgcc, on a Clang setup? Not sure if this is cc-rs's fault since there's no mention of that in the codebase.
But here is the erroring command! https://gist.github.com/lovelyyfiaaa/fdcf25749fad5253546d5e83d266d55f
togetherwithasteria
commented
2 years ago It seems my problem is related to https://github.com/rust-windowing/android-ndk-rs/pull/189?
plusls
commented
2 years ago Any progress?
I found that it is a bug in is_flag_supported, when use aarch64-linux-android33-clang.cmd in windows.
If I change it to let has_unwind = true;, it will compile success and without link lgcc.
This issue was originally filed as https://github.com/rust-lang/cargo/issues/7611, but @alexcrichton helped me understand that it is more likely an issue with the
cccrate itself.Problem
Using fresh installations of Rust installed on
x86_64-unknown-linux-gnu(Debian 9) via therustupmethod, compiling packages for Android with newer versions of the NDK does not work without overriding a number of tool paths manually.It seems like the Android targets expect older NDK toolchain binary name patterns. It also seems like rustc expects the host linker to be able to link target binaries, which seems wrong.
Steps
sh rustup-init.sh(fresh install for the local user)rustup target add aarch64-linux-androidCreate the hello world example from the documentation:
aarch64-linux-androidand it fails to link because it tries to use the host linker instead of the Android NDK linker:By specifying the location of the (r19c) NDK linker, we can avoid this problem:
Telling cargo and rustc where the Android NDK tools are seems reasonable, but it's odd that they default to using the system linker which isn't going to work. Using
PATHisn't enough because the Android NDK doesn't call its linker (or compiler) drivercc.Consider this trivial JNI project (which is from the docs with some parts deleted):
It builds fine for the host, but fails when targeting Android, even with the environment variable from above:
It seems that cargo is now looking for the actual Android NDK C compiler. Using
PATHisn't enough because even though the newer NDKs come with "already standalone" toolchains (and in fact the scripts that one used to use to copy the toolchains warn you not to, basically), the names of the compiler and linker drivers include the triplet and the API level integer.So the next iteration is to tell cargo via a different set of environment variables where the Android NDK C compiler is:
This gets further, but then it chokes on
aarch64-linux-android-arinstead:This time, the
PATHwill help because at least cargo is trying to invoke the tool with the right name:That's pretty awkward.
Questions
Have I misunderstood how to configure for Android cross targets?
Is there some unified way of specifying where the build tools should find the appropriate CC, AR, LD, for the target instead of using three different kinds of environment variables? Note that I purposely didn't use
~/.cargo/configor similar approaches because they didn't work for all of the required tools required by such builds, and those files can't use a variably-located Android NDK. Note how I am using$ANDROID_NDK_HOMEto find the NDK in all instances.Should the host linker really be used by default for cross target linking?
Have the Android targets been updated to be aware of the newer Android NDK toolchain naming conventions?
Thanks!
Notes
Output of
cargo version: