Do not use LFS64 on linux with musl#106246
Conversation
|
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@rustbot author Please use at-rustbot ready to push it back into my review queue when it is ready. |
|
@kraj |
|
☔ The latest upstream changes (presumably #106673) made this pull request unmergeable. Please resolve the merge conflicts. |
yeah I need to find time to rework this. |
|
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>
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
|
@kraj any updates on this? |
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>
|
Hey, can I take over this PR? |
|
@git-bruh sure feel free to submit a new pr and link to this one |
Please go ahead I won’t have time soon to work on it |
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`
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`
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``
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```
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```
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>
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>
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
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.
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.
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