Skip to content

Do not use LFS64 on linux with musl#106246

Closed
kraj wants to merge 1 commit into
rust-lang:masterfrom
kraj:master
Closed

Do not use LFS64 on linux with musl#106246
kraj wants to merge 1 commit into
rust-lang:masterfrom
kraj:master

Conversation

@kraj

@kraj kraj commented Dec 29, 2022

Copy link
Copy Markdown
Contributor

glibc is providing open64 and other lfs64 functions but musl aliases them to normal equivalents since off_t is always 64-bit on musl, therefore check for target env along when target OS is linux before using open64, this is more available. Latest Musl has made these namespace changes [1]

[1] https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4

@rustbot

rustbot commented Dec 29, 2022

Copy link
Copy Markdown
Collaborator

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 29, 2022
@rustbot

rustbot commented Dec 29, 2022

Copy link
Copy Markdown
Collaborator

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@thomcc

thomcc commented Dec 29, 2022

Copy link
Copy Markdown
Member

@rustbot author

Please use at-rustbot ready to push it back into my review queue when it is ready.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 29, 2022
@JohnCSimon

Copy link
Copy Markdown
Member

@kraj
Ping from triage - can you please address the reviewer's comments?

@bors

bors commented Mar 2, 2023

Copy link
Copy Markdown
Collaborator

☔ The latest upstream changes (presumably #106673) made this pull request unmergeable. Please resolve the merge conflicts.

@kraj

kraj commented Mar 3, 2023

Copy link
Copy Markdown
Contributor Author

@kraj Ping from triage - can you please address the reviewer's comments?

yeah I need to find time to rework this.

@alyssais alyssais mentioned this pull request May 2, 2023
47 tasks
@alyssais

Copy link
Copy Markdown
Contributor

Any news here? This is our main barrier to upgrading to musl 1.2.4 in Nixpkgs.

glibc is providing open64 and other lfs64 functions but musl aliases
them to normal equivalents since off_t is always 64-bit on musl,
therefore check for target env along when target OS is linux before
using open64, this is more available. Latest Musl has made these
namespace changes [1]

[1] https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4

Signed-off-by: Khem Raj <raj.khem@gmail.com>
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    |
299 | pub struct DirEntry {
    | ------------------- previous definition of the type `DirEntry` here
...
336 | pub struct DirEntry {
    | ^^^^^^^^^^^^^^^^^^^ `DirEntry` redefined here
    |
    = note: `DirEntry` must be defined only once in the type namespace of this module
error[E0432]: unresolved import `libc::fstatat64`
  --> /checkout/library/std/src/sys/unix/fs.rs:57:5
   |
57 | use libc::fstatat64;
57 | use libc::fstatat64;
   |     ^^^^^^---------
   |     |     |
   |     |     help: a similar name exists in the module: `fstatat`
   |     no `fstatat64` in the root

error[E0432]: unresolved imports `libc::dirent64`, `libc::fstat64`, `libc::ftruncate64`, `libc::lseek64`, `libc::lstat64`, `libc::off64_t`, `libc::open64`, `libc::stat64`
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek64, lstat64, off64_t, open64, stat64};
    |            |         |        |            |        |        |        |
    |            |         |        |            |        |        |        no `open64` in the root
    |            |         |        |            |        |        no `off64_t` in the root
    |            |         |        |            |        no `lstat64` in the root
    |            |         |        |            |        no `lstat64` in the root
    |            |         |        |            no `lseek64` in the root
    |            |         |        no `ftruncate64` in the root
    |            |         no `fstat64` in the root
    |            no `dirent64` in the root
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent, fstat64, ftruncate64, lseek64, lstat64, off64_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat, ftruncate64, lseek64, lstat64, off64_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate, lseek64, lstat64, off64_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek, lstat64, off64_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek64, lstat, off64_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek64, lstat64, off_t, open64, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek64, lstat64, off64_t, open, stat64};
help: a similar name exists in the module
    |
    |
106 | use libc::{dirent64, fstat64, ftruncate64, lseek64, lstat64, off64_t, open64, stat};

error[E0412]: cannot find type `dirent64_min` in this scope
    --> /checkout/library/std/src/sys/unix/fs.rs:301:12
     |
     |
301  |       entry: dirent64_min,
     |              ^^^^^^^^^^^^ help: a struct with a similar name exists: `dirent64`
     |
    ::: /cargo/registry/src/index.crates.io-6f17d22bba15001f/libc-0.2.143/src/unix/bsd/apple/mod.rs:1105:1
     |
1105 | / s_no_extra_traits! {
1106 | |     #[cfg_attr(libc_packedN, repr(packed(4)))]
1107 | |     pub struct kevent {
1108 | |         pub ident: ::uintptr_t,
1383 | |     }
1384 | | }
     | |_- similarly named struct `dirent64` defined here


error[E0063]: missing field `name` in initializer of `sys::unix::fs::DirEntry`
   --> /checkout/library/std/src/sys/unix/fs.rs:768:27
    |
768 |             let mut ret = DirEntry { entry: mem::zeroed(), dir: Arc::clone(&self.inner) };
    |                           ^^^^^^^^ missing `name`
Some errors have detailed explanations: E0063, E0412, E0428, E0432.
For more information about an error, try `rustc --explain E0063`.
error: could not compile `std` (lib) due to 5 previous errors
fatal error: failed to build sysroot: sysroot build failed

orbea added a commit to orbea/gentoo that referenced this pull request May 28, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 1, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 5, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 5, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 8, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 8, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 9, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jun 29, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

At this point USE=system-boostrap will be required with >= musl-1.2.4
until uptream merges these patches and updates their boostrap.

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jul 16, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jul 17, 2023
This fixes the build with musl-1.2.4, for those that are still
experiencing issues these steps should resolve them:

1. Downgrade to musl-1.2.3
2. Rebuild dev-lang/rust with these patches
3. Upgrade to musl-1.2.4 again
4. Rebuild rust with USE=system-bootstrap

This was tested with musl-1.2.3, musl-1.2.4 and glibc-2.37-r3.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jul 20, 2023
This fixes the build with musl-1.2.4, may need -system-bootstrap after
updating musl.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-Commit: rust-lang/libc@1e8c55c
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request Jul 21, 2023
This fixes the build with musl-1.2.4, may need -system-bootstrap after
updating musl.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-Commit: rust-lang/libc@1e8c55c
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
@Dylan-DPC

Copy link
Copy Markdown
Member

@kraj any updates on this?

orbea added a commit to orbea/gentoo that referenced this pull request Aug 7, 2023
This fixes the build with musl-1.2.4, may need -system-bootstrap after
updating musl.

Closes: https://bugs.gentoo.org/903607
Upstream-PR: rust-lang/rust#106246
Upstream-Issue: rust-lang/libc#2934
Upstream-PR: rust-lang/libc#2935
Upstream-Commit: rust-lang/libc@1e8c55c
Upstream-PR: rust-random/getrandom#326
Upstream-Commit: rust-random/getrandom@7f73e3c
Signed-off-by: orbea <orbea@riseup.net>
@git-bruh

Copy link
Copy Markdown

Hey, can I take over this PR?

@Dylan-DPC

Copy link
Copy Markdown
Member

@git-bruh sure feel free to submit a new pr and link to this one

@kraj

kraj commented Sep 19, 2023

Copy link
Copy Markdown
Contributor Author

Hey, can I take over this PR?

Please go ahead I won’t have time soon to work on it

@Dylan-DPC Dylan-DPC closed this Oct 12, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 28, 2023
Don't use LFS64 symbols on musl

Supersedes rust-lang#106246

~~Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files~~ Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc `@alyssais`
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Oct 29, 2023
Don't use LFS64 symbols on musl

Supersedes rust-lang#106246

~~Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files~~ Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc `@alyssais`
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 29, 2023
Don't use LFS64 symbols on musl

Supersedes rust-lang#106246

~~Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files~~ Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc ``@alyssais``
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 29, 2023
Don't use LFS64 symbols on musl

Supersedes rust-lang#106246

~~Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files~~ Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc ```@alyssais```
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 29, 2023
Rollup merge of rust-lang#115968 - git-bruh:master, r=workingjubilee

Don't use LFS64 symbols on musl

Supersedes rust-lang#106246

~~Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files~~ Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc ```@alyssais```
DesktopECHO added a commit to DesktopECHO/ika that referenced this pull request Jun 1, 2026
build-soong-arm64-host.patch overrode toolchainLinuxMuslArm64 to the GNU Rust
triple (aarch64-unknown-linux-gnu) "so rustc can load proc macros," then bolted
on linuxMuslArm64HostCross/rustTargetTriple to claw musl back only for the
host-cross (x86_64->arm64) case. On a NATIVE arm64 host, musl-linked host tools
(e.g. hiddenapi, now pulling Rust transitively via libcrypto_static) got the
GNU std, which references glibc LFS64 symbols (open64/lseek64/fstat64/stat64/
mmap64) that musl 1.2.4+ no longer exports publicly -> undefined-symbol link
failure.

Upstream already ships a correct musl toolchainLinuxMuslArm64 (musl triple +
LinuxMuslToolchain{Link,Rust}Flags), structurally identical to the working
x86_64 musl host toolchain, and modern Rust's musl std is LFS64-clean (libc
0.2.146 / rust-lang#106246). So drop the gnu-ification hunks and let arm64
mirror x86_64's proven musl path. Kept: the arm64-host enablement (bindgen
prebuilt tag, HostPrebuiltTag linux-arm64, proc-macro HostSupported) and all
non-rust hunks.

Refs: rust-lang/rust#111285, rust-lang/rust#106246
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DesktopECHO added a commit to DesktopECHO/ika that referenced this pull request Jun 1, 2026
Three speedups for the build engine that help on memory-constrained ARM64
hosts (e.g. a 16 GiB M1) without raising peak RSS:

- ccache (CCACHE_ENABLED=1 default): configure_ccache() installs/locates ccache,
  sizes the cache (CCACHE_MAX_SIZE, default 50G in CCACHE_DIR=<ika-root>/.ccache),
  exports USE_CCACHE/CCACHE_DIR/CCACHE_EXEC, and propagates them into the muvm
  guest. Soong honors USE_CCACHE for C/C++ (cc/config/global.go), so repeat and
  incremental builds drop a lot of compile time. Optional: a missing ccache only
  warns. First clean build sees ~no benefit.

- zram now prefers zstd (ZRAM_COMP_ALGORITHM, default zstd) over the kernel's
  lzo-rle, falling back if unavailable. Higher compression => more usable RAM
  before spilling to backing swap, paid on cores the memory-bound build leaves
  idle. The actual selected algorithm is logged.

- muvm guest now defaults to ALL logical host cores instead of a fixed 0-3.
  ARM64_JOBS still caps concurrent compilers, so the extra cores only speed the
  Soong analysis phase and zram threads -- no extra memory pressure. Overridable
  (pin "0-3" for M1 perf cores, or "" for muvm's own default).

docs/build-cli-help.txt updated for the new/changed knobs. bash -n clean;
--help intact; vCPU default/override and zram algorithm parse unit-tested.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Perf/observability: dump out/error.log on build failure

When a Soong/Ninja build fails, the concise failed-action detail is written to
out/error.log (full output goes to out/soong.log / verbose.log.gz). The muvm and
native build stdout can stay nearly silent through the long Soong analysis
phase, so a failure that lives only in error.log was invisible in our build log
-- a real failure cost ~84 min before the cause could be found by hand.

Add dump_soong_failure_logs() and call it on every failed attempt in
run_build_muvm and on failure in run_build_native, surfacing a capped tail of
out/error.log (prefixed) into the build log so failures are diagnosable
immediately.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): use upstream musl Rust toolchain instead of forcing GNU

build-soong-arm64-host.patch overrode toolchainLinuxMuslArm64 to the GNU Rust
triple (aarch64-unknown-linux-gnu) "so rustc can load proc macros," then bolted
on linuxMuslArm64HostCross/rustTargetTriple to claw musl back only for the
host-cross (x86_64->arm64) case. On a NATIVE arm64 host, musl-linked host tools
(e.g. hiddenapi, now pulling Rust transitively via libcrypto_static) got the
GNU std, which references glibc LFS64 symbols (open64/lseek64/fstat64/stat64/
mmap64) that musl 1.2.4+ no longer exports publicly -> undefined-symbol link
failure.

Upstream already ships a correct musl toolchainLinuxMuslArm64 (musl triple +
LinuxMuslToolchain{Link,Rust}Flags), structurally identical to the working
x86_64 musl host toolchain, and modern Rust's musl std is LFS64-clean (libc
0.2.146 / rust-lang#106246). So drop the gnu-ification hunks and let arm64
mirror x86_64's proven musl path. Kept: the arm64-host enablement (bindgen
prebuilt tag, HostPrebuiltTag linux-arm64, proc-macro HostSupported) and all
non-rust hunks.

Refs: rust-lang/rust#111285, rust-lang/rust#106246
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): revert to gnu Rust + add musl LFS64 alias compat shim

The pure-musl arm64 Rust switch (37394d3, 8ee4983) traded the hiddenapi *64
link failure for a proc-macro one: the GNU-host rustc (no musl arm64 rustc
prebuilt exists) can't load musl-built proc-macro .so's (E0463 on thiserror_impl).
Neither pure approach works while the rustc is gnu-host.

Revert both patches to the fork's working gnu-everything (proc macros load), and
fix the one remaining gap: the GNU Rust std references the glibc LFS64 symbols
(open64/lseek64/fstat64/stat64/mmap64/...), which musl 1.2.4 dropped as symbols
(it now provides them only as header macros). Re-add them as weak alias SYMBOLS
in each base function's source (#undef the macro first), restoring pre-1.2.4
musl behavior so gnu-std Rust staticlibs link into musl host tools.

Arch-safe: these are dormant weak symbols on x86_64/musl (whose Rust std is
LFS64-clean) and unused by the glibc x86_64 ROM host; only the native-arm64
gnu-rust path references them. Interim shim -- the proper fix is a musl-host
rustc (tracked separately).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): give musl-host bindgen the musl libc headers

bindgen (libbinder_ndk_bindgen) ran clang with -nostdlibinc --sysroot /dev/null
and got no musl -isystem includes -> sys/cdefs.h not found. rust muslDeps adds
libc_musl as a shared lib, but shared-lib exports don't reach SourceProviders
like bindgen; add the musl header libs (libc_musl_public_headers +
libc_musl_arch_headers) to muslDeps so their includes (incl. generated bits/ and
android/include cdefs) reach bindgen. Also stop tracking .ccache (build artifact).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Proactively shim gnu_get_libc_version + __res_init for musl host

Symbol audit (gnu Rust std undefined syms vs musl exports) found these two are
referenced by the std rlibs but absent in musl. hiddenapi linked clean without
them, so low-risk, but a future host tool could pull them. Add weak shims to
external/musl: __res_init aliases musl res_init; gnu_get_libc_version is a stub.
The __xstat64 family the audit also flagged is a false positive (0 rlib refs;
only in the prebuilt .so). Weak => dormant on x86_64 and unless actually pulled.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): call muslDeps for musl-host bindgen regardless of rust Glibc()

Root cause of the recurring bindgen sys/cdefs.h failure: bindgen SourceProviderDeps
gated muslDeps on (Os==LinuxMusl && !toolchain.Glibc()), but the gnu-everything
arm64 rust toolchain reports Glibc()=true, so muslDeps was never called for native
arm64 bindgen -> no musl libc headers -> cdefs not found. (My earlier muslDeps
header-libs addition was correct but dormant behind this gate.)

bindgen compiles C/C++ for the musl *cc* host, so it must use musl headers whenever
Os==LinuxMusl, independent of the rust toolchain's claimed libc. Change the bindgen
condition to ctx.Os()==android.LinuxMusl (bindgen-only; rust lib/binary deps stay
gnu by design). Combined with the muslDeps header-libs, bindgen now gets musl's
public+arch headers (incl. cdefs + generated bits/).

x86_64 unaffected (glibc-host ROM never hits LinuxMusl bindgen; x86_64-musl already
took this path).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): make musl public/arch header libs visible to bindgen consumers

With muslDeps now adding libc_musl_public_headers + libc_musl_arch_headers to
musl-host bindgen modules, Soong rejected them: those header libs are default-
private (libc_musl_headers is //bionic/libc-only). Set //visibility:public on
both (they are the public musl API headers).

Also fold two orphan out-of-band external/musl working-tree changes into this
managed patch so the build is reproducible: Android.bp -Wno-unterminated-string-
initialization (newer clang) and a src/stdio/vfprintf.c tweak.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): clean external/musl patch - drop stale orphan hunks

The previous regen folded two orphan working-tree changes (vfprintf.c, and a
context-stale Android.bp cflags hunk) that no longer applied to the synced
source -> patch-apply failure on a clean tree. Regenerate against pristine
external/musl with only the intended edits: 13 LFS64 *64 weak aliases, res_init
(__res_init alias + gnu_get_libc_version stub), //visibility:public on the musl
public/arch header libs, and a freshly-derived -Wno-unterminated-string-
initialization (needed under clang r584948b). Dropped the unknown vfprintf orphan.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DesktopECHO added a commit to DesktopECHO/ika that referenced this pull request Jun 1, 2026
Perf: ccache, zstd zram, and all-core muvm guest defaults

Three speedups for the build engine that help on memory-constrained ARM64
hosts (e.g. a 16 GiB M1) without raising peak RSS:

- ccache (CCACHE_ENABLED=1 default): configure_ccache() installs/locates ccache,
  sizes the cache (CCACHE_MAX_SIZE, default 50G in CCACHE_DIR=<ika-root>/.ccache),
  exports USE_CCACHE/CCACHE_DIR/CCACHE_EXEC, and propagates them into the muvm
  guest. Soong honors USE_CCACHE for C/C++ (cc/config/global.go), so repeat and
  incremental builds drop a lot of compile time. Optional: a missing ccache only
  warns. First clean build sees ~no benefit.

- zram now prefers zstd (ZRAM_COMP_ALGORITHM, default zstd) over the kernel's
  lzo-rle, falling back if unavailable. Higher compression => more usable RAM
  before spilling to backing swap, paid on cores the memory-bound build leaves
  idle. The actual selected algorithm is logged.

- muvm guest now defaults to ALL logical host cores instead of a fixed 0-3.
  ARM64_JOBS still caps concurrent compilers, so the extra cores only speed the
  Soong analysis phase and zram threads -- no extra memory pressure. Overridable
  (pin "0-3" for M1 perf cores, or "" for muvm's own default).

docs/build-cli-help.txt updated for the new/changed knobs. bash -n clean;
--help intact; vCPU default/override and zram algorithm parse unit-tested.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

# This is the commit message #2:

Perf/observability: dump out/error.log on build failure

When a Soong/Ninja build fails, the concise failed-action detail is written to
out/error.log (full output goes to out/soong.log / verbose.log.gz). The muvm and
native build stdout can stay nearly silent through the long Soong analysis
phase, so a failure that lives only in error.log was invisible in our build log
-- a real failure cost ~84 min before the cause could be found by hand.

Add dump_soong_failure_logs() and call it on every failed attempt in
run_build_muvm and on failure in run_build_native, surfacing a capped tail of
out/error.log (prefixed) into the build log so failures are diagnosable
immediately.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

# This is the commit message #3:

Fix(arm64): use upstream musl Rust toolchain instead of forcing GNU

build-soong-arm64-host.patch overrode toolchainLinuxMuslArm64 to the GNU Rust
triple (aarch64-unknown-linux-gnu) "so rustc can load proc macros," then bolted
on linuxMuslArm64HostCross/rustTargetTriple to claw musl back only for the
host-cross (x86_64->arm64) case. On a NATIVE arm64 host, musl-linked host tools
(e.g. hiddenapi, now pulling Rust transitively via libcrypto_static) got the
GNU std, which references glibc LFS64 symbols (open64/lseek64/fstat64/stat64/
mmap64) that musl 1.2.4+ no longer exports publicly -> undefined-symbol link
failure.

Upstream already ships a correct musl toolchainLinuxMuslArm64 (musl triple +
LinuxMuslToolchain{Link,Rust}Flags), structurally identical to the working
x86_64 musl host toolchain, and modern Rust's musl std is LFS64-clean (libc
0.2.146 / rust-lang#106246). So drop the gnu-ification hunks and let arm64
mirror x86_64's proven musl path. Kept: the arm64-host enablement (bindgen
prebuilt tag, HostPrebuiltTag linux-arm64, proc-macro HostSupported) and all
non-rust hunks.

Refs: rust-lang/rust#111285, rust-lang/rust#106246
DesktopECHO added a commit to DesktopECHO/ika that referenced this pull request Jun 1, 2026
The previous regen folded two orphan working-tree changes (vfprintf.c, and a
context-stale Android.bp cflags hunk) that no longer applied to the synced
source -> patch-apply failure on a clean tree. Regenerate against pristine
external/musl with only the intended edits: 13 LFS64 *64 weak aliases, res_init
(__res_init alias + gnu_get_libc_version stub), //visibility:public on the musl
public/arch header libs, and a freshly-derived -Wno-unterminated-string-
initialization (needed under clang r584948b). Dropped the unknown vfprintf orphan.

Perf: ccache, zstd zram, and all-core muvm guest defaults

Three speedups for the build engine that help on memory-constrained ARM64
hosts (e.g. a 16 GiB M1) without raising peak RSS:

- ccache (CCACHE_ENABLED=1 default): configure_ccache() installs/locates ccache,
  sizes the cache (CCACHE_MAX_SIZE, default 50G in CCACHE_DIR=<ika-root>/.ccache),
  exports USE_CCACHE/CCACHE_DIR/CCACHE_EXEC, and propagates them into the muvm
  guest. Soong honors USE_CCACHE for C/C++ (cc/config/global.go), so repeat and
  incremental builds drop a lot of compile time. Optional: a missing ccache only
  warns. First clean build sees ~no benefit.

- zram now prefers zstd (ZRAM_COMP_ALGORITHM, default zstd) over the kernel's
  lzo-rle, falling back if unavailable. Higher compression => more usable RAM
  before spilling to backing swap, paid on cores the memory-bound build leaves
  idle. The actual selected algorithm is logged.

- muvm guest now defaults to ALL logical host cores instead of a fixed 0-3.
  ARM64_JOBS still caps concurrent compilers, so the extra cores only speed the
  Soong analysis phase and zram threads -- no extra memory pressure. Overridable
  (pin "0-3" for M1 perf cores, or "" for muvm's own default).

docs/build-cli-help.txt updated for the new/changed knobs. bash -n clean;
--help intact; vCPU default/override and zram algorithm parse unit-tested.

Perf/observability: dump out/error.log on build failure

When a Soong/Ninja build fails, the concise failed-action detail is written to
out/error.log (full output goes to out/soong.log / verbose.log.gz). The muvm and
native build stdout can stay nearly silent through the long Soong analysis
phase, so a failure that lives only in error.log was invisible in our build log
-- a real failure cost ~84 min before the cause could be found by hand.

Add dump_soong_failure_logs() and call it on every failed attempt in
run_build_muvm and on failure in run_build_native, surfacing a capped tail of
out/error.log (prefixed) into the build log so failures are diagnosable
immediately.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): use upstream musl Rust toolchain instead of forcing GNU

build-soong-arm64-host.patch overrode toolchainLinuxMuslArm64 to the GNU Rust
triple (aarch64-unknown-linux-gnu) "so rustc can load proc macros," then bolted
on linuxMuslArm64HostCross/rustTargetTriple to claw musl back only for the
host-cross (x86_64->arm64) case. On a NATIVE arm64 host, musl-linked host tools
(e.g. hiddenapi, now pulling Rust transitively via libcrypto_static) got the
GNU std, which references glibc LFS64 symbols (open64/lseek64/fstat64/stat64/
mmap64) that musl 1.2.4+ no longer exports publicly -> undefined-symbol link
failure.

Upstream already ships a correct musl toolchainLinuxMuslArm64 (musl triple +
LinuxMuslToolchain{Link,Rust}Flags), structurally identical to the working
x86_64 musl host toolchain, and modern Rust's musl std is LFS64-clean (libc
0.2.146 / rust-lang#106246). So drop the gnu-ification hunks and let arm64
mirror x86_64's proven musl path. Kept: the arm64-host enablement (bindgen
prebuilt tag, HostPrebuiltTag linux-arm64, proc-macro HostSupported) and all
non-rust hunks.

Refs: rust-lang/rust#111285, rust-lang/rust#106246
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): revert to gnu Rust + add musl LFS64 alias compat shim

The pure-musl arm64 Rust switch (37394d3, 8ee4983) traded the hiddenapi *64
link failure for a proc-macro one: the GNU-host rustc (no musl arm64 rustc
prebuilt exists) can't load musl-built proc-macro .so's (E0463 on thiserror_impl).
Neither pure approach works while the rustc is gnu-host.

Revert both patches to the fork's working gnu-everything (proc macros load), and
fix the one remaining gap: the GNU Rust std references the glibc LFS64 symbols
(open64/lseek64/fstat64/stat64/mmap64/...), which musl 1.2.4 dropped as symbols
(it now provides them only as header macros). Re-add them as weak alias SYMBOLS
in each base function's source (#undef the macro first), restoring pre-1.2.4
musl behavior so gnu-std Rust staticlibs link into musl host tools.

Arch-safe: these are dormant weak symbols on x86_64/musl (whose Rust std is
LFS64-clean) and unused by the glibc x86_64 ROM host; only the native-arm64
gnu-rust path references them. Interim shim -- the proper fix is a musl-host
rustc (tracked separately).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): give musl-host bindgen the musl libc headers

bindgen (libbinder_ndk_bindgen) ran clang with -nostdlibinc --sysroot /dev/null
and got no musl -isystem includes -> sys/cdefs.h not found. rust muslDeps adds
libc_musl as a shared lib, but shared-lib exports don't reach SourceProviders
like bindgen; add the musl header libs (libc_musl_public_headers +
libc_musl_arch_headers) to muslDeps so their includes (incl. generated bits/ and
android/include cdefs) reach bindgen. Also stop tracking .ccache (build artifact).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Proactively shim gnu_get_libc_version + __res_init for musl host

Symbol audit (gnu Rust std undefined syms vs musl exports) found these two are
referenced by the std rlibs but absent in musl. hiddenapi linked clean without
them, so low-risk, but a future host tool could pull them. Add weak shims to
external/musl: __res_init aliases musl res_init; gnu_get_libc_version is a stub.
The __xstat64 family the audit also flagged is a false positive (0 rlib refs;
only in the prebuilt .so). Weak => dormant on x86_64 and unless actually pulled.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): call muslDeps for musl-host bindgen regardless of rust Glibc()

Root cause of the recurring bindgen sys/cdefs.h failure: bindgen SourceProviderDeps
gated muslDeps on (Os==LinuxMusl && !toolchain.Glibc()), but the gnu-everything
arm64 rust toolchain reports Glibc()=true, so muslDeps was never called for native
arm64 bindgen -> no musl libc headers -> cdefs not found. (My earlier muslDeps
header-libs addition was correct but dormant behind this gate.)

bindgen compiles C/C++ for the musl *cc* host, so it must use musl headers whenever
Os==LinuxMusl, independent of the rust toolchain's claimed libc. Change the bindgen
condition to ctx.Os()==android.LinuxMusl (bindgen-only; rust lib/binary deps stay
gnu by design). Combined with the muslDeps header-libs, bindgen now gets musl's
public+arch headers (incl. cdefs + generated bits/).

x86_64 unaffected (glibc-host ROM never hits LinuxMusl bindgen; x86_64-musl already
took this path).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): make musl public/arch header libs visible to bindgen consumers

With muslDeps now adding libc_musl_public_headers + libc_musl_arch_headers to
musl-host bindgen modules, Soong rejected them: those header libs are default-
private (libc_musl_headers is //bionic/libc-only). Set //visibility:public on
both (they are the public musl API headers).

Also fold two orphan out-of-band external/musl working-tree changes into this
managed patch so the build is reproducible: Android.bp -Wno-unterminated-string-
initialization (newer clang) and a src/stdio/vfprintf.c tweak.
DesktopECHO added a commit to DesktopECHO/ika that referenced this pull request Jun 1, 2026
The previous regen folded two orphan working-tree changes (vfprintf.c, and a
context-stale Android.bp cflags hunk) that no longer applied to the synced
source -> patch-apply failure on a clean tree. Regenerate against pristine
external/musl with only the intended edits: 13 LFS64 *64 weak aliases, res_init
(__res_init alias + gnu_get_libc_version stub), //visibility:public on the musl
public/arch header libs, and a freshly-derived -Wno-unterminated-string-
initialization (needed under clang r584948b). Dropped the unknown vfprintf orphan.

Perf: ccache, zstd zram, and all-core muvm guest defaults

Three speedups for the build engine that help on memory-constrained ARM64
hosts (e.g. a 16 GiB M1) without raising peak RSS:

- ccache (CCACHE_ENABLED=1 default): configure_ccache() installs/locates ccache,
  sizes the cache (CCACHE_MAX_SIZE, default 50G in CCACHE_DIR=<ika-root>/.ccache),
  exports USE_CCACHE/CCACHE_DIR/CCACHE_EXEC, and propagates them into the muvm
  guest. Soong honors USE_CCACHE for C/C++ (cc/config/global.go), so repeat and
  incremental builds drop a lot of compile time. Optional: a missing ccache only
  warns. First clean build sees ~no benefit.

- zram now prefers zstd (ZRAM_COMP_ALGORITHM, default zstd) over the kernel's
  lzo-rle, falling back if unavailable. Higher compression => more usable RAM
  before spilling to backing swap, paid on cores the memory-bound build leaves
  idle. The actual selected algorithm is logged.

- muvm guest now defaults to ALL logical host cores instead of a fixed 0-3.
  ARM64_JOBS still caps concurrent compilers, so the extra cores only speed the
  Soong analysis phase and zram threads -- no extra memory pressure. Overridable
  (pin "0-3" for M1 perf cores, or "" for muvm's own default).

docs/build-cli-help.txt updated for the new/changed knobs. bash -n clean;
--help intact; vCPU default/override and zram algorithm parse unit-tested.

Perf/observability: dump out/error.log on build failure

When a Soong/Ninja build fails, the concise failed-action detail is written to
out/error.log (full output goes to out/soong.log / verbose.log.gz). The muvm and
native build stdout can stay nearly silent through the long Soong analysis
phase, so a failure that lives only in error.log was invisible in our build log
-- a real failure cost ~84 min before the cause could be found by hand.

Add dump_soong_failure_logs() and call it on every failed attempt in
run_build_muvm and on failure in run_build_native, surfacing a capped tail of
out/error.log (prefixed) into the build log so failures are diagnosable
immediately.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): use upstream musl Rust toolchain instead of forcing GNU

build-soong-arm64-host.patch overrode toolchainLinuxMuslArm64 to the GNU Rust
triple (aarch64-unknown-linux-gnu) "so rustc can load proc macros," then bolted
on linuxMuslArm64HostCross/rustTargetTriple to claw musl back only for the
host-cross (x86_64->arm64) case. On a NATIVE arm64 host, musl-linked host tools
(e.g. hiddenapi, now pulling Rust transitively via libcrypto_static) got the
GNU std, which references glibc LFS64 symbols (open64/lseek64/fstat64/stat64/
mmap64) that musl 1.2.4+ no longer exports publicly -> undefined-symbol link
failure.

Upstream already ships a correct musl toolchainLinuxMuslArm64 (musl triple +
LinuxMuslToolchain{Link,Rust}Flags), structurally identical to the working
x86_64 musl host toolchain, and modern Rust's musl std is LFS64-clean (libc
0.2.146 / rust-lang#106246). So drop the gnu-ification hunks and let arm64
mirror x86_64's proven musl path. Kept: the arm64-host enablement (bindgen
prebuilt tag, HostPrebuiltTag linux-arm64, proc-macro HostSupported) and all
non-rust hunks.

Refs: rust-lang/rust#111285, rust-lang/rust#106246
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): point Rust std prebuilt + toolchain filegroup at musl rlibs

Completes the musl Rust switch. With build-soong-arm64-host.patch now using the
musl Rust triple (--target=aarch64-unknown-linux-musl), the std prebuilt link
dirs and the toolchain filegroup were still registered against the GNU rustlib
(aarch64-unknown-linux-gnu), so rustc compiled vendored crates (e.g.
unicode-ident) for the musl target but found only GNU core/std on -L ->
"couldn't find crate core with expected target triple aarch64-unknown-linux-musl".

Flip the arm64 host entries in prebuilts-rust-x86-musl-stdlib.patch from the GNU
to the musl triple (constructLibProps addPrebuiltToTarget x2 + rustToolchain
filegroup archTriple x2), mirroring the x86_64 musl host. The musl rustlib set
was verified complete (identical crate set to GNU: core/std/alloc/proc_macro/
test/...), so std stays prebuilt -- only vendored crates compile, now against
the musl std.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): revert to gnu Rust + add musl LFS64 alias compat shim

The pure-musl arm64 Rust switch (37394d3, 8ee4983) traded the hiddenapi *64
link failure for a proc-macro one: the GNU-host rustc (no musl arm64 rustc
prebuilt exists) can't load musl-built proc-macro .so's (E0463 on thiserror_impl).
Neither pure approach works while the rustc is gnu-host.

Revert both patches to the fork's working gnu-everything (proc macros load), and
fix the one remaining gap: the GNU Rust std references the glibc LFS64 symbols
(open64/lseek64/fstat64/stat64/mmap64/...), which musl 1.2.4 dropped as symbols
(it now provides them only as header macros). Re-add them as weak alias SYMBOLS
in each base function's source (#undef the macro first), restoring pre-1.2.4
musl behavior so gnu-std Rust staticlibs link into musl host tools.

Arch-safe: these are dormant weak symbols on x86_64/musl (whose Rust std is
LFS64-clean) and unused by the glibc x86_64 ROM host; only the native-arm64
gnu-rust path references them. Interim shim -- the proper fix is a musl-host
rustc (tracked separately).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): give musl-host bindgen the musl libc headers

bindgen (libbinder_ndk_bindgen) ran clang with -nostdlibinc --sysroot /dev/null
and got no musl -isystem includes -> sys/cdefs.h not found. rust muslDeps adds
libc_musl as a shared lib, but shared-lib exports don't reach SourceProviders
like bindgen; add the musl header libs (libc_musl_public_headers +
libc_musl_arch_headers) to muslDeps so their includes (incl. generated bits/ and
android/include cdefs) reach bindgen. Also stop tracking .ccache (build artifact).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Proactively shim gnu_get_libc_version + __res_init for musl host

Symbol audit (gnu Rust std undefined syms vs musl exports) found these two are
referenced by the std rlibs but absent in musl. hiddenapi linked clean without
them, so low-risk, but a future host tool could pull them. Add weak shims to
external/musl: __res_init aliases musl res_init; gnu_get_libc_version is a stub.
The __xstat64 family the audit also flagged is a false positive (0 rlib refs;
only in the prebuilt .so). Weak => dormant on x86_64 and unless actually pulled.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): call muslDeps for musl-host bindgen regardless of rust Glibc()

Root cause of the recurring bindgen sys/cdefs.h failure: bindgen SourceProviderDeps
gated muslDeps on (Os==LinuxMusl && !toolchain.Glibc()), but the gnu-everything
arm64 rust toolchain reports Glibc()=true, so muslDeps was never called for native
arm64 bindgen -> no musl libc headers -> cdefs not found. (My earlier muslDeps
header-libs addition was correct but dormant behind this gate.)

bindgen compiles C/C++ for the musl *cc* host, so it must use musl headers whenever
Os==LinuxMusl, independent of the rust toolchain's claimed libc. Change the bindgen
condition to ctx.Os()==android.LinuxMusl (bindgen-only; rust lib/binary deps stay
gnu by design). Combined with the muslDeps header-libs, bindgen now gets musl's
public+arch headers (incl. cdefs + generated bits/).

x86_64 unaffected (glibc-host ROM never hits LinuxMusl bindgen; x86_64-musl already
took this path).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fix(arm64): make musl public/arch header libs visible to bindgen consumers

With muslDeps now adding libc_musl_public_headers + libc_musl_arch_headers to
musl-host bindgen modules, Soong rejected them: those header libs are default-
private (libc_musl_headers is //bionic/libc-only). Set //visibility:public on
both (they are the public musl API headers).

Also fold two orphan out-of-band external/musl working-tree changes into this
managed patch so the build is reproducible: Android.bp -Wno-unterminated-string-
initialization (newer clang) and a src/stdio/vfprintf.c tweak.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants