build: target aarch64 over armv7, add rudimentary support for Rust components in build system, update to macOS SDK 15.0 (from Xcode 16.0)

[kwvg]

Additional Information

• Depends on backport: merge bitcoin#30423, #27038, #31048, #31099, #31172, #31450, #31608, #31818, #29881, #32458, #32400, #32760, #33178, #33312, #33780, #33181, #34102, partial bitcoin#29023, #30454, #30509, #30510, #31105, #32922, #33489, #33445 (build backports: part 5) #6927

• To ensure our list of targets validated are matched with targets used for releases (see guix-start), we switch out arm-linux-gnueabihf with aarch64-linux-gnu, this is now reflected by changes to our GitHub CI configuration, build scripts, Guix CI action.

  • Additionally, since dash#7047, we can't assume our host is x86_64 and must update packages to explicitly mention the desired arch instead of relying on that assumption.

• On top of ntdll.dll, Rust's standard library has a hard dependency on api-ms-win-core-synch-l1-2-0.dll (sync primitives) after rust-lang/rust#124019, which has been added to the allowlist even though this dependency isn't specified in RUST_LIBS.

• The build system passes information about the host compiler, target macOS version and other parameters as Rust crates themselves may be FFI bindings to C/C++ codebases, this is specifically relevant for cross-compilation where host and target do not match. depends exposes whatever is needed but if attempting to build without depends, the following environment variables need to be defined.

  • OSX_MIN_VERSION (target version of macOS)
  • OSX_SDK (path to the macOS SDK)
  • NATIVE_AR (host archiver)
  • NATIVE_CC (host C compiler)
  • NATIVE_CXX (host C++ compiler)
  • RUST_NATIVE (host Rust target, if cannot be deduced by build system)

• For integrating the crates into our C++ codebase, we use the cxx crate with the version defined in native_cxxbridge.mk

  • As mentioned in dash#6927, we need to update the macOS SDK to ensure we have standards-conformant definitions to deal with dtolnay/cxx#1574.

  • This does result in us using a higher SDK version than used upstream, requiring us to update the source URLs to our own fallback servers as upstream is not expected to host this version of the consolidated SDK. This has no effect on the target version of macOS, which will continue to be macOS 14.

• The version of Rust defined in native_rust.mk and rust-toolchain.toml must match as the former is what we use in depends (and is the same version used in the Guix environment, we don't rely on Guix to supply us a Rust build environment) and the latter is used to ensure that builds outside depends use a matching Rust version.

  • The version should also be synced with rust_stdlib.mk, which defines the standard libraries used. All hosts (native_rust) will have a target (rust_stdlib) but not all targets will have a host. Version management is done using contrib/devtools/update-rust-hashes.py and contrib/devtools/update-native-cxxbridge.py.

    • To avoid glibc-related issues in Guix builds due to conflicting versions, incompatible symbols or the mixing of code generated with different glibc targets, we have opted to use the musl variant of the standard library for Linux builds. Non-depends builds will need to configure their Rust environment accordingly.

    • To allow PowerPC target builds, we had to move from Rust 1.82 (the minimum version demanded by cxx) to 1.85.1

  • This also means that the CI Docker image does not have a Rust compiler as it is supplied by depends. This is done due to the fact that we already need a depends-supplied compiler to have greater control over version and variant but also to avoid increasing the size of our already-large master image.

    Future work on the CI system could provide Rust compilers to aid in debugging and development (as development images are derived from CI images) but that is out of scope for this PR.

• The depends system introduces the following verbs

  • download-rust-src (downloads packages necessary for vendoring)

  • download-rust-std (downloads the standard library for all targets listed in rust_stdlib.mk, needed as Guix environments do not have access to the internet)

  • vendor-dep-crates (vendors dependencies by Rust packages in the depends system)

  • vendor-all-crates (vendors dependencies by Rust packages used in the codebase)

    • During development and when building without the depends system, you will need to use --enable-online-rust, failing which, you will need to define RUST_VENDORED_SOURCES (a value that is otherwise defined by the depends system).

    • Vendoring support was added as Guix environments have no access to the internet and to allow for caching crates for CI.

• As the Guix environment does not use normal paths, we have to do the inverse of the patch that is usually done to binaries generated in Guix environments (replacing the loader with standard paths instead of store-specific paths) to ensure our native binaries will run and additionally locate the GCC runtime (libgcc_s.so.1) and move it to a location reachable to the native binaries and patch that patch too.

  This is done using contrib/guix/libexec/fix-elf-interpreter.sh and is meant only for the Guix environment as it assumes that it will always run on a Linux host.

How Has This Been Tested?

Running dashd or dash-qt should have this entry in their debug log (see below) demonstrating a call to the stub crate during init.

[...]
2026-01-19T12:56:31Z Command-line arg: testnet=""
2026-01-19T12:56:31Z chirp 0.1.0 built with rustc 1.85.1 (4eb161250 2025-03-15) reports "cheep cheep"
2026-01-19T12:56:31Z Using at most 125 automatic connections (285 file descriptors available)
2026-01-19T12:56:31Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2026-01-19T12:56:31Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
[...]

Breaking Changes

None expected.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

[github-actions]

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

[github-actions]

This pull request has conflicts, please rebase.

[github-actions]

This pull request has conflicts, please rebase.

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.0.2-devpr7109.9da49bec. A new comment will be made when the image is pushed.

[kwvg]

Checksums for 9da49be

0f51f16f49d3a8efc62f2ba64525ba4396fd0b90b19ddedcdbbb1b3fc427c9e1  dashcore-23.0.2-1141-g9da49becf786-aarch64-linux-gnu-debug.tar.gz
773d174467573a17d13496d3226d69a13ca92f2240e5e621e728c577cb491de7  dashcore-23.0.2-1141-g9da49becf786-aarch64-linux-gnu.tar.gz
3cdf72193aab45a9cf6c785f970792367b46b71f1872e4594c4f1a09a64d925f  dashcore-23.0.2-1141-g9da49becf786-arm64-apple-darwin-unsigned.tar.gz
7b121a02935960bcbccadd4f4fd1658f17e8f12756cf84aa68950794a8218063  dashcore-23.0.2-1141-g9da49becf786-arm64-apple-darwin-unsigned.zip
198d8672dfdb6d59e87fe2a2a02fdc72852307fb61747a672ebc34852e44f6a6  dashcore-23.0.2-1141-g9da49becf786-arm64-apple-darwin.tar.gz
4d3452ce53537c479085f258a3b4b2ceccfdf73a8a77e873dfafe0bfdb99b691  dashcore-23.0.2-1141-g9da49becf786.tar.gz
a24013dce08ba8a2e57ed8f2c4bd034faf017902dc35faebb3dd3224990844f2  dashcore-23.0.2-1141-g9da49becf786-riscv64-linux-gnu-debug.tar.gz
f24329eeb491805d786dda053e88e17bf0e8dce29ace4942504705b86830d751  dashcore-23.0.2-1141-g9da49becf786-riscv64-linux-gnu.tar.gz
53db55c0f86fa5806be73353dff5db8b5bfdd6a2ea986fa3f28d1a7adef2ef39  dashcore-23.0.2-1141-g9da49becf786-x86_64-apple-darwin-unsigned.tar.gz
fd214166e0f9cc5a10aa0a61bb0b0b5d3d5346e96f461313e9f9ffa0bd69eb06  dashcore-23.0.2-1141-g9da49becf786-x86_64-apple-darwin-unsigned.zip
81e615e643a0929bafe4d828c0e95f9985bf113b700a5f19c1c93e505f2a3132  dashcore-23.0.2-1141-g9da49becf786-x86_64-apple-darwin.tar.gz
b0a9fe3de1469d42d127dc31233952cfebaf88359d07e1c067132226889f358d  dashcore-23.0.2-1141-g9da49becf786-x86_64-linux-gnu-debug.tar.gz
2a9b7d1f2d960f5779c5671106dcc20521198114f1d6e29bd7c46af4749cc14b  dashcore-23.0.2-1141-g9da49becf786-x86_64-linux-gnu.tar.gz
c123023f8a457d93085d8bbd0581acfb7af4e5003c81231b2e14eaac6b2cebff  dashcore-23.0.2-1141-g9da49becf786-win64-debug.zip
ddf80e8991fa8a375fecc1999edd963e02c5623a4efc31aa01c4d05672a46781  dashcore-23.0.2-1141-g9da49becf786-win64-setup-unsigned.exe
9370fc622a528d080b1337624363f4cf408d705d7c083e7520a5491b678e8748  dashcore-23.0.2-1141-g9da49becf786-win64-unsigned.tar.gz
bb0a8ee290f1ae2d908a14d67877f5573d18e4e5def2654f1816b76632973a93  dashcore-23.0.2-1141-g9da49becf786-win64.zip

[DashCoreAutoGuix]

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v23.0.2-devpr7109.9da49bec. The image should be on dockerhub soon.

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.0.2-devpr7109.5443107c. A new comment will be made when the image is pushed.

[DashCoreAutoGuix]

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v23.0.2-devpr7109.5443107c. The image should be on dockerhub soon.

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.1.0-devpr7109.8084c966. A new comment will be made when the image is pushed.

[DashCoreAutoGuix]

Guix Automation has failed with an unknown error for tag v23.1.0-devpr7109.8084c966

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

contrib/guix/README.md (1)

225-227: ⚠️ Potential issue | 🟡 Minor

Documentation does not match actual HOSTS defaults in guix-build.

The README lists outdated defaults. The actual HOSTS in guix-build (line 84-86) includes riscv64-linux-gnu and excludes the disabled powerpc64le-linux-gnu, but the documented defaults omit the former and include the latter. Additionally, arm-linux-gnueabihf remains in both the actual defaults and documentation.

Update the documented HOSTS defaults to match the actual values in guix-build.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@contrib/guix/README.md` around lines 225 - 227, Update the documented HOSTS
defaults in the README to exactly match the actual HOSTS defined in guix-build:
add "riscv64-linux-gnu", remove the disabled "powerpc64le-linux-gnu", and keep
"arm-linux-gnueabihf" and the other existing entries (x86_64-linux-gnu,
aarch64-linux-gnu, powerpc64-linux-gnu, x86_64-w64-mingw32, x86_64-apple-darwin,
arm64-apple-darwin) so the README's HOSTS list mirrors the guix-build HOSTS
variable.

🧹 Nitpick comments (4)

depends/patches/native_rust/fix-elf-interpreter.sh (1)

54-61: cp to $LIBDIR without ensuring the directory exists.

If $LIBDIR does not already exist when reached, cp will fail. A mkdir -p guard would be more robust.

🛡️ Proposed fix

 if [ -n "$LIBGCC_SRC" ]; then
     # Resolve symlinks and copy the actual file
     LIBGCC_REAL=$(readlink -f "$LIBGCC_SRC")
     echo "Copying libgcc_s.so.1 from: $LIBGCC_REAL"
+    mkdir -p "$LIBDIR"
     cp "$LIBGCC_REAL" "$LIBDIR/libgcc_s.so.1"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@depends/patches/native_rust/fix-elf-interpreter.sh` around lines 54 - 61, The
script copies LIBGCC_REAL to $LIBDIR but doesn't ensure $LIBDIR exists, causing
cp to fail; update the block that uses LIBGCC_SRC, LIBGCC_REAL and LIBDIR to
create the destination directory first (e.g., run mkdir -p "$LIBDIR" before cp)
and handle errors (exit or warn) if mkdir or cp fails so the subsequent cp
"$LIBGCC_REAL" "$LIBDIR/libgcc_s.so.1" is robust.

depends/config.site.in (2)

177-186: RUST_VENDORED_SOURCES is set unconditionally, unlike the other Rust tool variables.

CARGO, RUSTC, and CXXBRIDGE are only set when the binary exists under the depends prefix. RUST_VENDORED_SOURCES is always set—even in non-depends builds where the vendored-sources directory may not exist—potentially passing a stale/invalid path to configure.

♻️ Proposed alignment (optional)

-RUST_VENDORED_SOURCES="${depends_prefix}/vendored-sources"
+if test -d "${depends_prefix}/vendored-sources"; then
+  RUST_VENDORED_SOURCES="${depends_prefix}/vendored-sources"
+fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@depends/config.site.in` around lines 177 - 186, RUST_VENDORED_SOURCES is
being set unconditionally which can pass a non-existent path into configure;
change it to mirror the conditional pattern used for CARGO, RUSTC, and CXXBRIDGE
by only setting RUST_VENDORED_SOURCES when "${depends_prefix}/vendored-sources"
exists (test -d) — use the same depends_prefix variable and add a conditional
block that assigns RUST_VENDORED_SOURCES only if the directory is present,
leaving it unset otherwise.

---

113-116: NATIVE_AR always overrides a user-set value, unlike NATIVE_CC/NATIVE_CXX.

NATIVE_CC and NATIVE_CXX are guarded with -a -z "${NATIVE_CC}" so a user-provided value is preserved. NATIVE_AR follows the existing (non-native) AR pattern of always overriding. This is internally consistent within each pair, but the asymmetry across the three native tool variables may surprise callers who pre-set NATIVE_AR.

If the intent is to match the NATIVE_CC/NATIVE_CXX semantics:

♻️ Proposed alignment (optional)

-if test -n "@NATIVE_AR@"; then
+if test -n "@NATIVE_AR@" -a -z "${NATIVE_AR}"; then
   NATIVE_AR="@NATIVE_AR@"
   ac_cv_path_NATIVE_AR="${NATIVE_AR}"
 fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@depends/config.site.in` around lines 113 - 116, The NATIVE_AR assignment
always overrides a user-provided value unlike NATIVE_CC/NATIVE_CXX; update the
block that sets NATIVE_AR and ac_cv_path_NATIVE_AR so it only assigns when
`@NATIVE_AR`@ is non-empty and the user hasn't already set NATIVE_AR (i.e., add
the same test pattern used for NATIVE_CC/NATIVE_CXX such as checking -n
"@NATIVE_AR@" and -z "${NATIVE_AR}" before setting NATIVE_AR and
ac_cv_path_NATIVE_AR) to preserve pre-set NATIVE_AR values.

contrib/devtools/update-native-cxxbridge.py (1)

69-72: cargo invoked via partial path without output capture.

subprocess.run uses a bare "cargo" command name (S607). This is acceptable for a developer tool, but consider capturing stderr so failures produce a more informative diagnostic than just "cargo check failed".

Optional improvement

         result = subprocess.run(
             ["cargo", "check", "--release", "--package=cxxbridge-cmd", "--bin=cxxbridge"],
             cwd=cxx_dir,
+            capture_output=True,
+            text=True,
         )
         if result.returncode != 0:
-            print("Error: cargo check failed", file=sys.stderr)
+            print("Error: cargo check failed", file=sys.stderr)
+            if result.stderr:
+                print(result.stderr, file=sys.stderr)
             return 1

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@contrib/devtools/update-native-cxxbridge.py` around lines 69 - 72, The
subprocess.run call that invokes cargo (the call assigning to result using
subprocess.run([...], cwd=cxx_dir)) does not capture stderr, so failures lack
diagnostic output; modify this call to capture output (e.g., add
capture_output=True or stdout=subprocess.PIPE, stderr=subprocess.PIPE) and on
non-zero return (result.returncode != 0) log or raise including result.stderr
(and optionally result.stdout) so failing cargo check emits the command output
for debugging.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.gitignore:
- Around line 179-200: Remove the unanchored, overly-broad entries: delete the
bare "debug" entry, replace the bare "target" with a rooted "/target" (or
explicitly ignore "/target/debug" if you only mean build artifacts), and replace
the bare "gen" with a rooted form like "/gen" or "/gen/" so the ignores only
apply to top-level build/generated dirs; update the .gitignore entries
referencing "debug", "target", and "gen" accordingly.

In `@contrib/guix/README.md`:
- Line 252: The README line references Xcode 16.0 (build `16A242d`) but claims a
macOS SDK 15.2; update that example to reference the correct Xcode build that
contains macOS SDK 15.2 by replacing the string containing
`Xcode-16.0-16A242d-extracted-SDK-with-libcxx-headers` (the
`$HOME/Downloads/...` path) with the Xcode 16.2 build identifier and SDK name
(e.g., `Xcode-16.2-16C5032a-extracted-SDK-with-libcxx-headers` and `macosx15.2`)
so the documented SDK identifier matches the claimed SDK version.

In `@contrib/macdeploy/README.md`:
- Line 18: The README currently references Xcode_16.xip but incorrectly states
SDK 15.2; either update the PR title/description to indicate SDK 15.0/Xcode 16.0
(build 16A242d) or switch the referenced artifact to Xcode 16.2 (build 16C5032a)
to truly target SDK 15.2; if switching to Xcode 16.2, update the tarball name
and the sha256 values accordingly (the generated tarball name and its sha256
must match the Xcode 16.2 release), and verify that the sha256 hashes shown (the
entries near lines referencing the hash values) were produced from a clean
extraction of the exact Xcode release you choose.

In `@depends/patches/native_rust/fix-elf-interpreter.sh`:
- Around line 75-77: The verification block unconditionally runs patchelf on
"$1" after the initial shift, which causes errors when no binaries were passed;
modify the script so the two commands (patchelf --print-interpreter "$1" and
patchelf --print-rpath "$1") are only executed when "$1" is non-empty (i.e.,
after shift check that at least one binary argument exists), guarding the
verification with a simple conditional that skips the patchelf calls when there
are no binary arguments.

---

Outside diff comments:
In `@contrib/guix/README.md`:
- Around line 225-227: Update the documented HOSTS defaults in the README to
exactly match the actual HOSTS defined in guix-build: add "riscv64-linux-gnu",
remove the disabled "powerpc64le-linux-gnu", and keep "arm-linux-gnueabihf" and
the other existing entries (x86_64-linux-gnu, aarch64-linux-gnu,
powerpc64-linux-gnu, x86_64-w64-mingw32, x86_64-apple-darwin,
arm64-apple-darwin) so the README's HOSTS list mirrors the guix-build HOSTS
variable.

---

Duplicate comments:
In @.cargo/config.toml.offline:
- Around line 14-15: The linker setting under the
target.x86_64-unknown-linux-musl section is using the incorrect hyphenated
binary name "x86-64-linux-gnu-gcc"; update the linker value to the correct
cross-compiler executable "x86_64-linux-gnu-gcc" (replace the hyphen between x86
and 64 with an underscore) so the linker resolves correctly.

In `@configure.ac`:
- Around line 1753-1760: The fallback to $(sw_vers -productVersion) for
RUST_MACOS_DEPLOYMENT_TARGET can fail during cross-compilation; update the block
that sets RUST_MACOS_DEPLOYMENT_TARGET so it only calls sw_vers when
OSX_MIN_VERSION is unset AND the build is actually running on macOS and sw_vers
exists (similar guard used around RUST_OSX_SDK). In practice, replace the
unconditional fallback with a conditional that checks the host is darwin and
that command -v sw_vers >/dev/null succeeds before invoking sw_vers, otherwise
leave RUST_MACOS_DEPLOYMENT_TARGET empty (or unchanged).
- Around line 1743-1751: The current case block appends -ldl for all non-mingw
hosts (the RUST_LIBS assignment inside the case $host block), which wrongly
applies to macOS/FreeBSD; change the pattern matching so -ldl is only added for
Linux hosts (e.g., replace the *) branch that sets RUST_LIBS="$RUST_LIBS -ldl"
with an explicit pattern like *linux* or *linux*|*gnu*), and add a separate
default/no-op branch for other OSes (macOS/FreeBSD) so they do not receive -ldl.
- Around line 130-143: RS_REQUIRE_PROG currently leaves shell expansions
unquoted and uses a double-quoted AC_MSG_ERROR; update the macro so the test
uses quoted expansions (e.g. test "x${$1}" = "x${2_notfound}" or equivalent
quoted forms) to handle paths with spaces, and change the error call to use m4
square-bracket quoting for AC_MSG_ERROR (AC_MSG_ERROR([Required program $2 was
not found])) so the message is properly quoted by autoconf; keep the same
symbols RS_REQUIRE_PROG, AC_PATH_PROG and AC_MSG_ERROR when making the change.

In `@contrib/devtools/update-native-cxxbridge.py`:
- Around line 56-57: The call to tar.extractall(tmp_path) is vulnerable to path
traversal; update the extraction in the tarfile.open block to use a safe filter
(e.g., pass filter="data" when calling tar.extractall) or otherwise validate
members' paths before extraction so extracted files cannot escape tmp_path;
locate the tarfile.open(...) as well as tar.extractall(tmp_path) and change the
extraction to use the filter="data" argument (or implement an explicit member
path-sanitization routine) referencing tarfile.extractall, tarfile.open,
tarball_path and tmp_path.

In `@contrib/guix/symbol-check.py`:
- Around line 151-159: The PE_ALLOWED_LIBRARIES set has continuation-line
indentation that triggers Flake8 E122; fix the indentation of the items inside
PE_ALLOWED_LIBRARIES so continuation lines are either aligned under the opening
brace or use a consistent hanging indent (e.g., indent the subsequent lines to
match the first element or use 4 spaces), ensuring each string literal like
'ADVAPI32.dll', 'api-ms-win-core-synch-l1-2-0.dll', etc. is properly aligned and
the closing brace lines up correctly with the opening brace.
- Around line 244-247: The function check_MACHO_sdk currently compares
binary.build_version.sdk to [15, 0, 0] but the PR updates the SDK to 15.2;
update the comparison in check_MACHO_sdk to match the new SDK tuple (e.g., [15,
2, 0]) so the function returns True for the correct SDK version and avoid the
mismatch between code and PR title.

In `@depends/funcs.mk`:
- Around line 304-310: The macro download_rust_std_target currently writes the
.stamp_fetched-rust_stdlib... hash file unconditionally after attempting a
download; modify it so the downloaded tarball is verified with the project's
SHA256 checker (e.g. invoke $(build_SHA256SUM) -c or reuse the fetch_file
hash-check logic against $(rust_stdlib_sha256_hash_$(1)) and the downloaded
"$(SOURCES_PATH)/rust-std-$(rust_stdlib_version)-$(1).tar.gz") and only write
the stamp file (the
"download-stamps/.stamp_fetched-rust_stdlib-$(rust_stdlib_version)-$(rust_stdlib_sha256_hash_$(1)).hash"
target) when the verification succeeds; on verification failure, fail the rule
and do not create the stamp.
- Around line 329-339: The tar extraction in the int_cargo_preprocess_ext macro
uses $(build_TAR) -P -xf $(SOURCES_PATH)/$($(1)_vendored_file_name) which can
preserve ownership when run as root; update the command inside
int_cargo_preprocess_ext to include --no-same-owner (matching other extractions)
so it becomes $(build_TAR) --no-same-owner -P -xf ... to avoid
permission/ownership problems when extracting vendored crates.

In `@rust/Makefile.chirp.include`:
- Around line 46-52: The Makefile recipe for target LIBRUST_CHIRP_H has mixed
leading whitespace in the else branch (the $(CXXBRIDGE) invocation): remove the
leading spaces and ensure the recipe line begins with a single tab character so
all recipe lines under the if/else use a proper leading tab; verify similar
recipe lines (the cp and the $(CXXBRIDGE) lines) start with tabs and not spaces
to avoid Makefile parsing issues (references: LIBRUST_CHIRP_H,
LIBRUST_CHIRP_GEN_SRCDIR, CXXBRIDGE).

---

Nitpick comments:
In `@contrib/devtools/update-native-cxxbridge.py`:
- Around line 69-72: The subprocess.run call that invokes cargo (the call
assigning to result using subprocess.run([...], cwd=cxx_dir)) does not capture
stderr, so failures lack diagnostic output; modify this call to capture output
(e.g., add capture_output=True or stdout=subprocess.PIPE,
stderr=subprocess.PIPE) and on non-zero return (result.returncode != 0) log or
raise including result.stderr (and optionally result.stdout) so failing cargo
check emits the command output for debugging.

In `@depends/config.site.in`:
- Around line 177-186: RUST_VENDORED_SOURCES is being set unconditionally which
can pass a non-existent path into configure; change it to mirror the conditional
pattern used for CARGO, RUSTC, and CXXBRIDGE by only setting
RUST_VENDORED_SOURCES when "${depends_prefix}/vendored-sources" exists (test -d)
— use the same depends_prefix variable and add a conditional block that assigns
RUST_VENDORED_SOURCES only if the directory is present, leaving it unset
otherwise.
- Around line 113-116: The NATIVE_AR assignment always overrides a user-provided
value unlike NATIVE_CC/NATIVE_CXX; update the block that sets NATIVE_AR and
ac_cv_path_NATIVE_AR so it only assigns when `@NATIVE_AR`@ is non-empty and the
user hasn't already set NATIVE_AR (i.e., add the same test pattern used for
NATIVE_CC/NATIVE_CXX such as checking -n "@NATIVE_AR@" and -z "${NATIVE_AR}"
before setting NATIVE_AR and ac_cv_path_NATIVE_AR) to preserve pre-set NATIVE_AR
values.

In `@depends/patches/native_rust/fix-elf-interpreter.sh`:
- Around line 54-61: The script copies LIBGCC_REAL to $LIBDIR but doesn't ensure
$LIBDIR exists, causing cp to fail; update the block that uses LIBGCC_SRC,
LIBGCC_REAL and LIBDIR to create the destination directory first (e.g., run
mkdir -p "$LIBDIR" before cp) and handle errors (exit or warn) if mkdir or cp
fails so the subsequent cp "$LIBGCC_REAL" "$LIBDIR/libgcc_s.so.1" is robust.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Overly broad unanchored ignore patterns (debug, target, gen).

• debug (line 181): Cargo never creates a standalone top-level debug/ directory (debug artefacts live under target/debug/), so this entry is both redundant and risks silently hiding any debug/ directory that might appear elsewhere in the repo.
• target (line 182): Without a leading /, this matches every target/ directory in the entire tree (e.g. src/target/, contrib/target/, etc.). Standard Rust .gitignore templates use the rooted /target form.
• gen (line 200): Bare name with no leading / and no glob qualifier – would silently hide any file or directory named gen anywhere in the repository.

🔧 Suggested tightening

-debug
-target
+/target

...

-gen
+rust/gen

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gitignore around lines 179 - 200, Remove the unanchored, overly-broad
entries: delete the bare "debug" entry, replace the bare "target" with a rooted
"/target" (or explicitly ignore "/target/debug" if you only mean build
artifacts), and replace the bare "gen" with a rooted form like "/gen" or "/gen/"
so the ignores only apply to top-level build/generated dirs; update the
.gitignore entries referencing "debug", "target", and "gen" accordingly.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Unconditional patchelf verification on $1 will error when no binaries are supplied.

After the shift at line 8, $1 is the first binary argument. If the script is invoked with only LIBDIR and no binary arguments, $1 is empty and both patchelf calls fail, leaving the script with a non-zero exit code. Guard the verification block:

🐛 Proposed fix

-echo "Verifying first binary:"
-patchelf --print-interpreter "$1"
-patchelf --print-rpath "$1"
+if [ -n "$1" ]; then
+    echo "Verifying first binary:"
+    patchelf --print-interpreter "$1"
+    patchelf --print-rpath "$1"
+fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@depends/patches/native_rust/fix-elf-interpreter.sh` around lines 75 - 77, The
verification block unconditionally runs patchelf on "$1" after the initial
shift, which causes errors when no binaries were passed; modify the script so
the two commands (patchelf --print-interpreter "$1" and patchelf --print-rpath
"$1") are only executed when "$1" is non-empty (i.e., after shift check that at
least one binary argument exists), guarding the verification with a simple
conditional that skips the patchelf calls when there are no binary arguments.

[DashCoreAutoGuix]

Guix Automation has began to build this PR tagged as v23.1.0-devpr7109.415bcf34. A new comment will be made when the image is pushed.

[DashCoreAutoGuix]

Guix Automation has failed with an unknown error for tag v23.1.0-devpr7109.415bcf34

[kwvg]

Checksums for 415bcf3

88f9029df37b677b5b1b17f9ac8de51da2ee419c325e82e199608b027ee444b2  dashcore-23.1.0-97-g415bcf341e19-aarch64-linux-gnu-debug.tar.gz
92a4781538b1da5e6bb29fb0cb55dd88db523a9634dab693953c9763177acc8f  dashcore-23.1.0-97-g415bcf341e19-aarch64-linux-gnu.tar.gz
04830fddaf2c8178d722ed3a7be1da24362167612b08c1b18b3a9f02cae6958b  dashcore-23.1.0-97-g415bcf341e19-arm64-apple-darwin-unsigned.tar.gz
bab9b3b73d614b5020ec405457f251554e38af0c6a9ee85888624805e2ed3853  dashcore-23.1.0-97-g415bcf341e19-arm64-apple-darwin-unsigned.zip
3335fab57a36e38a811aa8bac5f645ba969d5f8578ecd3faa5ed8b626942b40e  dashcore-23.1.0-97-g415bcf341e19-arm64-apple-darwin.tar.gz
98b7221a1a81724bb3bdd8bc9bc20d15b589eb2fcead42530e2d426204301b4a  dashcore-23.1.0-97-g415bcf341e19.tar.gz
0b637c9e9b9156491220a6882d58c1145e43ef5ca2004819b3b6154b28c2bf6c  dashcore-23.1.0-97-g415bcf341e19-riscv64-linux-gnu-debug.tar.gz
fb3b1d989a68eee7e5d4a8b98e0b2683617cc896c4b93001103b43e17eda4e4a  dashcore-23.1.0-97-g415bcf341e19-riscv64-linux-gnu.tar.gz
964a94f5f0a0d54091be4f93cdbe9294a0a87045df2425674137312b4d984e3e  dashcore-23.1.0-97-g415bcf341e19-x86_64-apple-darwin-unsigned.tar.gz
66f574ae41308698e39259da91d3fc1652f438f554d007eb7dff6a9741b13cff  dashcore-23.1.0-97-g415bcf341e19-x86_64-apple-darwin-unsigned.zip
4d58f4213e81a6cc2ff9d1b0ed987d4784ee423154456aa663b67977648eb03a  dashcore-23.1.0-97-g415bcf341e19-x86_64-apple-darwin.tar.gz
b839a81ae5f4750a52fcfd4f12b69bd0f94a531722569cea0fb7b27b19586b6b  dashcore-23.1.0-97-g415bcf341e19-x86_64-linux-gnu-debug.tar.gz
bc67f093168d5fbcf8b17dc7ba19bf3db885002bed1aa816baf32b777fa03701  dashcore-23.1.0-97-g415bcf341e19-x86_64-linux-gnu.tar.gz
09541a2c7c2593466445d473df082e61b7aa2abbc7ee6c90985d3e13c45caa75  dashcore-23.1.0-97-g415bcf341e19-win64-debug.zip
a1cd0ad92cf75f031ceb6678eb092c3f6bd60629eea8f18a4de6b563264107e4  dashcore-23.1.0-97-g415bcf341e19-win64-setup-unsigned.exe
4fa0cf945f9208e94948206eed5d6fd93c19b12b163a4d6af3bdf90f38dc5a16  dashcore-23.1.0-97-g415bcf341e19-win64-unsigned.tar.gz
51ddac97dfde22ef1762c644165d67e5c366224beaf8fb1a9c7df4f83276c0bf  dashcore-23.1.0-97-g415bcf341e19-win64.zip

[thepastaclaw]

❌ Guix build failed for tag v23.1.0-devpr7109.415bcf34. Check logs for details.

[thepastaclaw]

✅ Guix build complete! Release: https://github.com/dashpay/dash-dev-branches/releases/tag/v23.1.0-devpr7109.415bcf34

Binaries:

• dashcore-23.1.0-devpr7109.415bcf34-x86_64-linux-gnu.tar.gz (59MB)
• dashcore-23.1.0-devpr7109.415bcf34-aarch64-linux-gnu.tar.gz (35MB)

Built on native aarch64 Linux VM with Guix 1.5.0.