Create an abomination #99
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bbqsrc
force-pushed
the
feature/windows-r25-workaround
branch
5 times, most recently
from
671207f to
75cf74b
Compare
So there's a bug where NDK r25 doesn't handle command line args properly to clang. Which is precisely what rustc calls, and breaks. Highly paid teams at Google in their infinite wisdom implemented argument handling with [reads notes] wizardry, wishful thinking, and ... fucking batch scripts in 2023. `.cmd` files. For arg parsing! ON WINDOWS! WHAT IN THE NAME OF ZOMBIE JESUS. Anyway. So now cargo-ndk will use the actual Win32 function for parsing args before handing them off to their cursed batch files. It took 2 hours to workaround this issue. The bug in the NDK repo has been open for 3 months. I should invoice Google at this point. android/ndk#1856
bbqsrc
force-pushed
the
feature/windows-r25-workaround
branch
from
75cf74b to
35a315e
Compare
|
Tested it on a number of major crates, it works. |
|
|
|
Huge thanks for taking a look at this issue, this was a big pain for me recently! Unfortunately it looks like this breaks setting the 'platform' / api level because Clang itself parses the name of the executable to pull out the api level from the name, such that I guess the hard link names should be defined based on |
|
(maybe it works though since I suppose |
|
Yeah it doesn't matter what the names are because it simply grabs the correct path and calls it via another environment variable. Essentially it just maps the args and then calls whatever.cmd, which is still the original name. 🙂 |
|
My CARGO_HOME is set to F:\Cargo, and temp path is "C:\TEMP" haha H:\rust\flashdrop>cargo ndk -t arm64-v8a build
[2023-05-10T12:41:32Z INFO cargo_ndk::cli] Using NDK at path: D:\compiler\Android\ndk\25.0.8775105 (ANDROID_HOME)
[2023-05-10T12:41:32Z INFO cargo_ndk::cli] NDK API level: 21
[2023-05-10T12:41:32Z INFO cargo_ndk::cli] Building targets: arm64-v8a
[2023-05-10T12:41:32Z INFO cargo_ndk::cli] Building arm64-v8a (aarch64-linux-android)
Cargo.rs:139 main: F:\Cargo\bin\cargo-ndk.exe f:"C:\\TEMP\\.tmpbaLHAs\\ar.exe"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 17, kind: CrossesDevices, message: "
系统无法将文件移到不同的磁盘驱动器。" }', src\cargo.rs:140:81
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace |
|
lol fucking Windows. I’ll fix today, thanks for reporting! |
Thank you very much 👍 |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I did And test it PS D:\rustpj\learn> cargo ndk -t armeabi-v7a -t arm64-v8a -o ./jniLibs build --release
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] Using NDK at path: D:\AndroidSDK\ndk\25.2.9519653 (NDK_HOME)
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] NDK API level: 21
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] Building targets: armeabi-v7a, arm64-v8a
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] Building armeabi-v7a (armv7-linux-androideabi)
Compiling example v0.1.0 (D:\rustpj\learn)
Finished release [optimized] target(s) in 0.09s
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] Building arm64-v8a (aarch64-linux-android)
Compiling example v0.1.0 (D:\rustpj\learn)
Finished release [optimized] target(s) in 0.09s
[2023-05-10T17:40:17Z INFO cargo_ndk::cli] Copying libraries to ./jniLibs...
[2023-05-10T17:40:17Z ERROR cargo_ndk::cli] No .so files found in path "D:\\rustpj\\learn\\target\\armv7-linux-androideabi\\release"
[2023-05-10T17:40:17Z ERROR cargo_ndk::cli] Did you set the crate-type in Cargo.toml to include 'cdylib'?
[2023-05-10T17:40:17Z ERROR cargo_ndk::cli] For more info, see <https://doc.rust-lang.org/cargo/reference/cargo-targets.html#library>.
PS D:\rustpj\learn> my cargo.toml is same as the example folder on this repo. but doing cargo ndk -t armeabi-v7a build only [2023-05-10T17:43:07Z INFO cargo_ndk::cli] Using NDK at path: D:\AndroidSDK\ndk\25.2.9519653 (NDK_HOME)
[2023-05-10T17:43:07Z INFO cargo_ndk::cli] NDK API level: 21
[2023-05-10T17:43:07Z INFO cargo_ndk::cli] Building targets: armeabi-v7a
[2023-05-10T17:43:07Z INFO cargo_ndk::cli] Building armeabi-v7a (armv7-linux-androideabi)
Compiling example v0.1.0 (D:\rustpj\learn)
Finished dev [unoptimized + debuginfo] target(s) in 0.17sI dont see any .so output xD |
PS D:\rustpj\learn> cargo ndk -t armeabi-v7a -t arm64-v8a -o ./jniLibs build --release
[2023-05-11T08:58:55Z INFO cargo_ndk::cli] Using NDK at path: D:\AndroidSDK\ndk\25.2.9519653 (NDK_HOME)
[2023-05-11T08:58:55Z INFO cargo_ndk::cli] NDK API level: 21
[2023-05-11T08:58:55Z INFO cargo_ndk::cli] Building targets: armeabi-v7a, arm64-v8a
[2023-05-11T08:58:55Z INFO cargo_ndk::cli] Building armeabi-v7a (armv7-linux-androideabi)
Compiling example v0.1.0 (D:\rustpj\learn)
Finished release [optimized] target(s) in 1.05s
[2023-05-11T08:58:57Z INFO cargo_ndk::cli] Building arm64-v8a (aarch64-linux-android)
Compiling example v0.1.0 (D:\rustpj\learn)
Finished release [optimized] target(s) in 0.57s
[2023-05-11T08:58:57Z INFO cargo_ndk::cli] Copying libraries to ./jniLibs...
[2023-05-11T08:58:57Z INFO cargo_ndk::cli] D:\rustpj\learn\target\armv7-linux-androideabi\release\libexample.so -> ./jniLibs\armeabi-v7a\libexample.so
[2023-05-11T08:58:57Z INFO cargo_ndk::cli] D:\rustpj\learn\target\aarch64-linux-android\release\libexample.so -> ./jniLibs\arm64-v8a\libexample.so
PS D:\rustpj\learn> got the .so files lets gooooooooooooooooooo xD this might be out of the topic but. since we use android ndk to compile ... how do we pass cxx/c flags. where should i put it? |
|
The rules for doing that are the same as with cargo and rustc, cargo ndk still just passes through all the flags as it did before. |
|
Love you, worked for me 🌹 |
Unfortunately The quoting issue is fixed, yay! (I was seeing an issue with the quoting of a linker script, similar to one of the other reports) but now I'm seeing an issue with the command line apparently being too long. This is the command that it's upset about: Click meI have some vague recollection that by default windows programs have some really silly limit on the length of commands they can spawn, but I'm not sure off the top of my head what's needed to bump that limit. |
|
It looks like that command is about 12k, which is > the 8k limit. I'm not quite sure how cargo / rustc overcome that limit though |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #92.
@TomieAi can you test this and let me know if it fixes your issue?