-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] clang.cmd
doesn't work well with -march=armv7-a
#1856
Comments
@rprichard could you look at this for r26? I think you understand the cmd stuff better than the rest of us. |
Maybe https://stackoverflow.com/a/26079381
I wonder if our wrappers can forward arguments containing special characters, like |
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
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
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
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
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
I also encountered this problem. I've found that if What helped me was to replace this line
with
The |
I also just arrived at the same workaround as @vbieleny |
Isn't the idea to ditch the |
At least for my current use case i'm using the toolchain via cargo/rustc and I'm not sure if there's any practical way yet to specify the target api level via cargo afaik? (adding the api level suffix wouldn't be a valid target name for rust) so at least for now it's still useful to have these wrappers. |
In |
|
Rust unfortunately seems to be rare in how we can provide the linker... by needing a different nontrivial environment var ( I wonder if we could have added it to the |
Just for reference, I gave this a try and cargo expects to be able to resolve the Unfortunately right now it looks like it's very difficult to pass As discussed here bbqsrc/cargo-ndk#104 (comment); tools such as Unfortunately that means that the solution mentioned above for The best solution for Rust projects would probably be to look at adding Alternatively I think Cargo and the Without something like that then I think we need to continue using these One other approach I may investigate is to treat |
to package manager developers and build system developers, maybe write your own wrapper in C API is a better choice. here is a example I'm using https://github.com/leleliu008/ndk-pkg/blob/master/ndk-pkg-wrapper-cc.c write your own wrapper, you can do many things. let's show you some examples:
|
This is an alternative workaround for bbqsrc#92 that's similar to the solution used in ndk-build except that the `-Clink-arg rustflag` is injected via a RUSTC_WRAPPER instead of trying to modify CARGO_ENCODED_RUSTFLAGS. It turned out to be practically impossible to be able to reliably set CARGO_ENCODED_RUSTFLAGS without risking trampling over rustflags that might be configured via Cargo (for example `target.<cfg>.rustflags` are especially difficult to read outside of cargo itself) This approach avoids hitting the command line length limitations of the current workaround and avoids needing temporary hard links or copying the cargo-ndk binary to the target/ directory. Even though we've only seen quoting issues with the Windows `.cmd` wrappers this change to avoid using the wrapper scripts is being applied consistently for all platforms. E.g. considering the upstream recommendation to avoid the wrapper scripts if possible: https://android-review.googlesource.com/c/platform/ndk/+/2134712 Fixes: bbqsrc#92 Fixes: bbqsrc#104 Addresses: android/ndk#1856
This is an alternative workaround for bbqsrc#92 that's similar to the solution used in ndk-build except that the `-Clink-arg rustflag` is injected via a RUSTC_WRAPPER instead of trying to modify CARGO_ENCODED_RUSTFLAGS. It turned out to be practically impossible to be able to reliably set CARGO_ENCODED_RUSTFLAGS without risking trampling over rustflags that might be configured via Cargo (for example `target.<cfg>.rustflags` are especially difficult to read outside of cargo itself) This approach avoids hitting the command line length limitations of the current workaround and avoids needing temporary hard links or copying the cargo-ndk binary to the target/ directory. Even though we've only seen quoting issues with the Windows `.cmd` wrappers this change to avoid using the wrapper scripts is being applied consistently for all platforms. E.g. considering the upstream recommendation to avoid the wrapper scripts if possible: https://android-review.googlesource.com/c/platform/ndk/+/2134712 Fixes: bbqsrc#92 Fixes: bbqsrc#104 Addresses: android/ndk#1856
This is an alternative workaround for bbqsrc#92 that's similar to the solution used in ndk-build except that the `--target=<triple><api-level>` argument for Clang is injected by using cargo-ndk as a linker wrapper instead of trying to modify CARGO_ENCODED_RUSTFLAGS. It turned out to be practically impossible to be able to reliably set CARGO_ENCODED_RUSTFLAGS without risking trampling over rustflags that might be configured via Cargo (for example `target.<cfg>.rustflags` are especially difficult to read outside of cargo itself) This approach avoids hitting the command line length limitations of the current workaround and avoids needing temporary hard links or copying the cargo-ndk binary to the target/ directory. Even though we've only seen quoting issues with the Windows `.cmd` wrappers this change to avoid using the wrapper scripts is being applied consistently for all platforms. E.g. considering the upstream recommendation to avoid the wrapper scripts if possible: https://android-review.googlesource.com/c/platform/ndk/+/2134712 Fixes: bbqsrc#92 Fixes: bbqsrc#104 Addresses: android/ndk#1856
This is an alternative workaround for #92 that's similar to the solution used in ndk-build except that the `--target=<triple><api-level>` argument for Clang is injected by using cargo-ndk as a linker wrapper instead of trying to modify CARGO_ENCODED_RUSTFLAGS. It turned out to be practically impossible to be able to reliably set CARGO_ENCODED_RUSTFLAGS without risking trampling over rustflags that might be configured via Cargo (for example `target.<cfg>.rustflags` are especially difficult to read outside of cargo itself) This approach avoids hitting the command line length limitations of the current workaround and avoids needing temporary hard links or copying the cargo-ndk binary to the target/ directory. Even though we've only seen quoting issues with the Windows `.cmd` wrappers this change to avoid using the wrapper scripts is being applied consistently for all platforms. E.g. considering the upstream recommendation to avoid the wrapper scripts if possible: https://android-review.googlesource.com/c/platform/ndk/+/2134712 Fixes: #92 Fixes: #104 Addresses: android/ndk#1856
https://android-review.googlesource.com/c/platform/ndk/+/2925163 incorporates @vbieleny's suggested fix. Thanks! I need to wait for presubmit to finish with it before I can verify it, but I should be able to do that later today. |
Confirmed, fix merged. |
Description
I've installed NDK 25.2.9519653 and want to work with rust. However, the content of
*-*-*-clang.cmd
causes issues. The content of such cmd script is:The fourth line,
if "%1" == "-cc1" goto :L
, causes issues. Rust put a param"-march=armv7-a"
with armv7a target, and cmd will throw errorThat's because the line is interpreted as
if ""-march=armv7-a"" == "-cc1" goto :L
. When I comment out this line, it works well.Affected versions
r25
Canary version
No response
Host OS
Windows
Host OS version
Windows 11
Affected ABIs
armeabi-v7a
Build system
ndk-build
Other build system
No response
minSdkVersion
24
Device API level
No response
The text was updated successfully, but these errors were encountered: