remove build.rs for android #656
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
fengys1996
changed the title
bjorn3
reviewed
Aug 23, 2024
Cargo.toml
Outdated
| @@ -74,7 +68,6 @@ serialize-serde = ["serde"] | |||
| # purposes. New code should use none of these features. | |||
| coresymbolication = [] | |||
| dbghelp = [] | |||
| dl_iterate_phdr = [] | |||
There was a problem hiding this comment.
This feature itself should probably remain for back compat reasons. It would just do nothing.
|
Do we need to bump the |
fengys1996
changed the title
fengys1996
changed the title
|
Don't worry about the version bump, I'll take care of that in due time. |
ConradIrwin
referenced
this pull request
in zed-industries/zed
Sep 19, 2024
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [backtrace](https://redirect.github.com/rust-lang/backtrace-rs) | dependencies | patch | `0.3.73` -> `0.3.74` | | [backtrace](https://redirect.github.com/rust-lang/backtrace-rs) | dev-dependencies | patch | `0.3.73` -> `0.3.74` | --- ### Release Notes <details> <summary>rust-lang/backtrace-rs (backtrace)</summary> ### [`v0.3.74`](https://redirect.github.com/rust-lang/backtrace-rs/releases/tag/0.3.74) [Compare Source](https://redirect.github.com/rust-lang/backtrace-rs/compare/0.3.73...0.3.74) #### What's Changed - QNX Neutrino 7.0 support, thanks to [@​nyurik](https://redirect.github.com/nyurik) in [https://github.com/rust-lang/backtrace-rs/pull/648](https://redirect.github.com/rust-lang/backtrace-rs/pull/648) - Cleaned up our Android support. This should massively improve backtraces for ones with the API level sufficient to ship with libunwind, etc. Unfortunately, it comes at the cost of dropping support for older ones! Thanks to [@​fengys](https://redirect.github.com/fengys) in [https://github.com/rust-lang/backtrace-rs/pull/656](https://redirect.github.com/rust-lang/backtrace-rs/pull/656) - Made PrintFmt, which was using the `Enum::__NonExhaustiveVariant` pattern, use `#[non_exhaustive]` for real. Don't @​ me if you were matching on that! Thanks to [@​nyurik](https://redirect.github.com/nyurik) in [https://github.com/rust-lang/backtrace-rs/pull/651](https://redirect.github.com/rust-lang/backtrace-rs/pull/651) - Massively cleaned up the windows code! We moved from winapi to windows-sys with windows-targets thanks to [@​CraftSpider](https://redirect.github.com/CraftSpider) and [@​ChrisDenton](https://redirect.github.com/ChrisDenton) in - Don't cast HANDLE to usize and back by [@​CraftSpider](https://redirect.github.com/CraftSpider) in [https://github.com/rust-lang/backtrace-rs/pull/635](https://redirect.github.com/rust-lang/backtrace-rs/pull/635) - Switch from `winapi` to `windows-sys` by [@​CraftSpider](https://redirect.github.com/CraftSpider) in [https://github.com/rust-lang/backtrace-rs/pull/641](https://redirect.github.com/rust-lang/backtrace-rs/pull/641) - Update windows bindings and use windows-targets by [@​ChrisDenton](https://redirect.github.com/ChrisDenton) in [https://github.com/rust-lang/backtrace-rs/pull/653](https://redirect.github.com/rust-lang/backtrace-rs/pull/653) - A bunch of updated dependencies. Thanks [@​djc](https://redirect.github.com/djc) and [@​khuey](https://redirect.github.com/khuey)! - Sorry if you were testing this code in miri! It started yelling about sussy casts. A lot. We did a bunch of internal cleanups that should make it quiet down, thanks to [@​workingjubilee](https://redirect.github.com/workingjubilee) in [https://github.com/rust-lang/backtrace-rs/pull/641](https://redirect.github.com/rust-lang/backtrace-rs/pull/641) - Uhhh we had to tweak `dl_iterate_phdr` in [https://github.com/rust-lang/backtrace-rs/pull/660](https://redirect.github.com/rust-lang/backtrace-rs/pull/660) after Android revealed it was... kind of unsound actually and not doing things like checking for null pointers before making slices! WHOOPS! Thanks to [@​saethlin](https://redirect.github.com/saethlin) for implementing detection for precisely that in rustc! It's really hard to find soundness issues in inherited codebases like this one... #### New Contributors - [@​CraftSpider](https://redirect.github.com/CraftSpider) made their first contribution in [https://github.com/rust-lang/backtrace-rs/pull/635](https://redirect.github.com/rust-lang/backtrace-rs/pull/635) - [@​fengys1996](https://redirect.github.com/fengys1996) made their first contribution in [https://github.com/rust-lang/backtrace-rs/pull/656](https://redirect.github.com/rust-lang/backtrace-rs/pull/656) - [@​djc](https://redirect.github.com/djc) made their first contribution in [https://github.com/rust-lang/backtrace-rs/pull/657](https://redirect.github.com/rust-lang/backtrace-rs/pull/657) **Full Changelog**: rust-lang/backtrace-rs@0.3.73...0.3.74 </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone America/New_York, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- Release Notes: - N/A <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC44MC4wIiwidXBkYXRlZEluVmVyIjoiMzguODAuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Note that the linked upgrade only made it into Rust 1.82. Does that mean that if one is compiling Perhaps the MSRV of this crate should be bumped to 1.82 to that effect (already bumped to 1.79 in #689), even if that seems a bit harsh just for Android. |
MarijnS95
added a commit
to rust-mobile/xbuild
that referenced
this pull request
Jan 7, 2025
We haven't set the SDK/API level via the `__ANDROID_API__` define for a very long time and so far got away with it. However, while debugging why `backtrace` (and by extension Rust `std` which reuses that crate) wasn't generating symbolicated stacktraces in `panic_log`, and why `findshlibs` wasn't providing the list of loaded libraries to `sentry`, we found that both rely on expanding the `__ANDROID_API__` define via compiling a small C file via `cc` to make the code conditional on SDK/API >= 21: gimli-rs/findshlibs#65 rust-lang/backtrace-rs#415 (It would have been lovely if these crates emitted a `cargo:warning` when the define wasn't set at all, indicating an "incomplete" cross-compiler setup, and/or looked at the runtime Android API version via something like rust-mobile/ndk#479.) Note that `backtrace 0.3.74` / Rust 1.82 (rust-lang/rust@0763a3a) no longer rely on this because Rust 1.82 bumped the minimum SDK/API level to 21: rust-lang/backtrace-rs#656 We could set this define directly, or rely on `clang` to set it for us by appending the SDK/API level to the target triple, of the form `<arch>-linux-android<sdk level>`. The latter is more common. Keep in mind that the `cc` crate adds an unversioned `--target=<arch>-linux-android` to the command line arguments as well, but clang seems to deduplicate them (or look at the latter `--target` which contains our version). Note that this effectively reverts 32efed6 because we must now always pass the SDK level via the triple again, even if the host also happens to be Android with the same architecture.
MarijnS95
added a commit
to Traverse-Research/xbuild
that referenced
this pull request
Jan 7, 2025
We haven't set the SDK/API level via the `__ANDROID_API__` define for a very long time and so far got away with it. However, while debugging why `backtrace` (and by extension Rust `std` which reuses that crate) wasn't generating symbolicated stacktraces in `panic_log`, and why `findshlibs` wasn't providing the list of loaded libraries to `sentry`, we found that both rely on expanding the `__ANDROID_API__` define via compiling a small C file via `cc` to make the code conditional on SDK/API >= 21: gimli-rs/findshlibs#65 rust-lang/backtrace-rs#415 (It would have been lovely if these crates emitted a `cargo:warning` when the define wasn't set at all, indicating an "incomplete" cross-compiler setup, and/or looked at the runtime Android API version via something like rust-mobile/ndk#479.) Note that `backtrace 0.3.74` / Rust 1.82 (rust-lang/rust@0763a3a) no longer rely on this because Rust 1.82 bumped the minimum SDK/API level to 21: rust-lang/backtrace-rs#656 We could set this define directly, or rely on `clang` to set it for us by appending the SDK/API level to the target triple, of the form `<arch>-linux-android<sdk level>`. The latter is more common. Keep in mind that the `cc` crate adds an unversioned `--target=<arch>-linux-android` to the command line arguments as well, but clang seems to deduplicate them (or look at the latter `--target` which contains our version). Note that this effectively reverts rust-mobile@32efed6 because we must now always pass the SDK level via the triple again, even if the host also happens to be Android with the same architecture.
MarijnS95
added a commit
to Traverse-Research/xbuild
that referenced
this pull request
Jan 9, 2025
We haven't set the SDK/API level via the `__ANDROID_API__` define for a very long time and so far got away with it. However, while debugging why `backtrace` (and by extension Rust `std` which reuses that crate) wasn't generating symbolicated stacktraces in `panic_log`, and why `findshlibs` wasn't providing the list of loaded libraries to `sentry`, we found that both rely on expanding the `__ANDROID_API__` define via compiling a small C file via `cc` to make the code conditional on SDK/API >= 21: gimli-rs/findshlibs#65 rust-lang/backtrace-rs#415 (It would have been lovely if these crates emitted a `cargo:warning` when the define wasn't set at all, indicating an "incomplete" cross-compiler setup, and/or looked at the runtime Android API version via something like rust-mobile/ndk#479.) Note that `backtrace 0.3.74` / Rust 1.82 (rust-lang/rust@0763a3a) no longer rely on this because Rust 1.82 bumped the minimum SDK/API level to 21: rust-lang/backtrace-rs#656 We could set this define directly, or rely on `clang` to set it for us by appending the SDK/API level to the target triple, of the form `<arch>-linux-android<sdk level>`. The latter is more common. Keep in mind that the `cc` crate adds an unversioned `--target=<arch>-linux-android` to the command line arguments as well, but clang seems to deduplicate them (or look at the latter `--target` which contains our version). Note that this effectively reverts rust-mobile@32efed6 because we must now always pass the SDK level via the triple again, even if the host also happens to be Android with the same architecture.
MarijnS95
added a commit
to rust-mobile/xbuild
that referenced
this pull request
Jan 9, 2025
We haven't set the SDK/API level via the `__ANDROID_API__` define for a very long time and so far got away with it. However, while debugging why `backtrace` (and by extension Rust `std` which reuses that crate) wasn't generating symbolicated stacktraces in `panic_log`, and why `findshlibs` wasn't providing the list of loaded libraries to `sentry`, we found that both rely on expanding the `__ANDROID_API__` define via compiling a small C file via `cc` to make the code conditional on SDK/API >= 21: gimli-rs/findshlibs#65 rust-lang/backtrace-rs#415 (It would have been lovely if these crates emitted a `cargo:warning` when the define wasn't set at all, indicating an "incomplete" cross-compiler setup, and/or looked at the runtime Android API version via something like rust-mobile/ndk#479.) Note that `backtrace 0.3.74` / Rust 1.82 (rust-lang/rust@0763a3a) no longer rely on this because Rust 1.82 bumped the minimum SDK/API level to 21: rust-lang/backtrace-rs#656 We could set this define directly, or rely on `clang` to set it for us by appending the SDK/API level to the target triple, of the form `<arch>-linux-android<sdk level>`. The latter is more common. Keep in mind that the `cc` crate adds an unversioned `--target=<arch>-linux-android` to the command line arguments as well, but clang seems to deduplicate them (or look at the latter `--target` which contains our version). Note that this effectively reverts 32efed6 because we must now always pass the SDK level via the triple again, even if the host also happens to be Android with the same architecture.
MarijnS95
added a commit
to Traverse-Research/xbuild
that referenced
this pull request
Jan 9, 2025
We haven't set the SDK/API level via the `__ANDROID_API__` define for a very long time and so far got away with it. However, while debugging why `backtrace` (and by extension Rust `std` which reuses that crate) wasn't generating symbolicated stacktraces in `panic_log`, and why `findshlibs` wasn't providing the list of loaded libraries to `sentry`, we found that both rely on expanding the `__ANDROID_API__` define via compiling a small C file via `cc` to make the code conditional on SDK/API >= 21: gimli-rs/findshlibs#65 rust-lang/backtrace-rs#415 (It would have been lovely if these crates emitted a `cargo:warning` when the define wasn't set at all, indicating an "incomplete" cross-compiler setup, and/or looked at the runtime Android API version via something like rust-mobile/ndk#479.) Note that `backtrace 0.3.74` / Rust 1.82 (rust-lang/rust@0763a3a) no longer rely on this because Rust 1.82 bumped the minimum SDK/API level to 21: rust-lang/backtrace-rs#656 We could set this define directly, or rely on `clang` to set it for us by appending the SDK/API level to the target triple, of the form `<arch>-linux-android<sdk level>`. The latter is more common. Keep in mind that the `cc` crate adds an unversioned `--target=<arch>-linux-android` to the command line arguments as well, but clang seems to deduplicate them (or look at the latter `--target` which contains our version). Note that this effectively reverts rust-mobile@32efed6 because we must now always pass the SDK level via the triple again, even if the host also happens to be Android with the same architecture.
MarijnS95
added a commit
to MarijnS95/findshlibs
that referenced
this pull request
Jan 9, 2025
Since Rust 1.82 the minimum Android API level is 21. In `backtrace`, this warranted the removal of the API version check via `__ANDROID_API__` in rust-lang/backtrace-rs#656 since it is now always known to be >=21. When `findshlibs` bumps its MSRV the same could be done. This change is sparked by a long search for why backtraces always had `<unknown>` symbols on Android - and when solving that by upgrading Rust (for `std::backtrace`) or our `backtrace` dependency, why Sentry reports did not record what images/libraries were loaded at which offsets to resolve stack addresses back to function symbols. It turned out that the `xbuild` build tool never set `__ANDROID_API__` (by not telling `clang` about the target API level via the triple) which would cause this code to never set `feature = "dl_iterate_phdr"` to search for libraries on Android: rust-mobile/xbuild#209
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.
Since rust-lang/rust#120593 the minimum android API level is 21.
Related
https://github.com/android/ndk/wiki/Changelog-r26
rust-lang/rust#129305
dl_iterate_phdrbased on whether the android API level is greater than or equal to 21, but retain it for back compat.ccbuild dependency.