Remove stale jerboa-coreutils dependency from Rust coreutils builds #79

New issue

Open

opened 2026-09-12 19:58:09 -04:00 by ober · 0 comments

ober commented

2026-09-12 19:58:09 -04:00

Owner

Problem

The shell is supposed to use the Rust/uutils based coreutils implementation (rust-coreutils / libjsh_coreutils.a), but the build still vendors, stages, and embeds the Scheme jerboa-coreutils tree in multiple paths. This leaves the project in a hybrid state where the Rust archive provides the native command engine, while jerboa-coreutils still appears to provide Scheme modules, wrappers, and C shim glue.

This is confusing and risky because a build may silently depend on the older Scheme jerboa-coreutils modules even though the intended implementation is Rust coreutils.

Evidence found

Root repo references:

Makefile still defines COREUTILS ?= $(VENDOR)/jerboa-coreutils/lib.
Makefile includes $(COREUTILS) in LIBDIRS_JSH and XC_LIBDIRS.
Makefile still includes jerboa-coreutils in VENDOR_REPOS and LINUX_VENDOR_REPOS.
build-jsh-macos.sh sets COREUTILS_DIR="${COREUTILS_DIR:-$(dep jerboa-coreutils lib)}" while also building/exporting RUST_COREUTILS_LIB.
build-jsh-freebsd.sh similarly sets COREUTILS_DIR from jerboa-coreutils while also building Rust coreutils.
build-jsh-macos.ss stages jerboa-coreutils modules and also links libjsh_coreutils.a.
build-jsh-freebsd.ss stages jerboa-coreutils modules and also links libjsh_coreutils.a.
build-jsh-musl.ss appears closer to the desired state: it explicitly says jerboa-coreutils is replaced by Rust uutils and does not compile Scheme coreutils modules.

Extras/Android references observed in vendor/jerboa-shell-extras after bootstrap:

vendor/jerboa-shell-extras/Makefile still defines COREUTILS ?= $(VENDOR)/jerboa-coreutils/lib.
vendor/jerboa-shell-extras/Makefile still vendors jerboa-coreutils in VENDOR_REPOS and LINUX_VENDOR_REPOS.
vendor/jerboa-shell-extras/build-jsh-android.sh sets COREUTILS_DIR="${COREUTILS_DIR:-${VENDOR}/jerboa-coreutils/lib}".
vendor/jerboa-shell-extras/build-jsh-android.sh also builds rust-coreutils/target/release/libjsh_coreutils.a, so Android is definitely hybrid.
vendor/jerboa-shell-extras/build-jsh-android.ss defines coreutils-dir as ${vendor-dir}/jerboa-coreutils/lib.
vendor/jerboa-shell-extras/build-jsh-android.ss embeds a long list of jerboa-coreutils/... Scheme modules into the Android boot image.
vendor/jerboa-shell-extras/build-jsh-android.ss compiles vendor/jerboa-coreutils/support/libcoreutils.c into coreutils-ffi.o.
The same Android builder also links libjsh_coreutils.a with --whole-archive.

Why this matters

It is unclear which implementation actually owns each coreutils command.
The build can accidentally keep depending on stale Scheme modules from jerboa-coreutils.
Android boot images become larger and more fragile because they include many jerboa-coreutils modules even though Rust coreutils is linked.
Portability fixes may be applied to the wrong implementation.
Release/debugging expectations become misleading: “Rust coreutils” may still require jerboa-coreutils to be present.

Expected direction

If Rust coreutils is the intended implementation, the build should converge on:

rust-coreutils / libjsh_coreutils.a as the only command implementation.
Local jsh/coreutils and jsh/coreutils-shim wrappers only, if wrappers are still needed.
No jerboa-coreutils entry in root or extras vendor dependency lists unless it is truly still required.
No $(VENDOR)/jerboa-coreutils/lib in libdirs.
No Android boot embedding of jerboa-coreutils/... modules.
No compile of vendor/jerboa-coreutils/support/libcoreutils.c if Rust FFI symbols cover the command surface.

Suggested acceptance criteria

Audit every remaining jerboa-coreutils reference and classify it as required glue, obsolete wrapper, or stale dependency.
Remove stale references from root and extras build files.
Ensure macOS, Linux, FreeBSD, and Android builders all use Rust coreutils consistently.
Keep the musl builder's Rust-only approach as the model unless a platform-specific reason exists.
Add a test or build assertion that selected Rust-coreutils builds do not require vendor/jerboa-coreutils/lib for command dispatch.
Document any intentionally retained compatibility layer, including why it is still needed and when it can be removed.

This surfaced while investigating Android/Termux all-features build issues. The Android builder was observed to both build/link libjsh_coreutils.a and embed/compile jerboa-coreutils Scheme/C support, which contradicts the expectation that coreutils should come from Rust.

## Problem The shell is supposed to use the Rust/uutils based coreutils implementation (`rust-coreutils` / `libjsh_coreutils.a`), but the build still vendors, stages, and embeds the Scheme `jerboa-coreutils` tree in multiple paths. This leaves the project in a hybrid state where the Rust archive provides the native command engine, while `jerboa-coreutils` still appears to provide Scheme modules, wrappers, and C shim glue. This is confusing and risky because a build may silently depend on the older Scheme `jerboa-coreutils` modules even though the intended implementation is Rust coreutils. ## Evidence found Root repo references: - `Makefile` still defines `COREUTILS ?= $(VENDOR)/jerboa-coreutils/lib`. - `Makefile` includes `$(COREUTILS)` in `LIBDIRS_JSH` and `XC_LIBDIRS`. - `Makefile` still includes `jerboa-coreutils` in `VENDOR_REPOS` and `LINUX_VENDOR_REPOS`. - `build-jsh-macos.sh` sets `COREUTILS_DIR="${COREUTILS_DIR:-$(dep jerboa-coreutils lib)}"` while also building/exporting `RUST_COREUTILS_LIB`. - `build-jsh-freebsd.sh` similarly sets `COREUTILS_DIR` from `jerboa-coreutils` while also building Rust coreutils. - `build-jsh-macos.ss` stages `jerboa-coreutils` modules and also links `libjsh_coreutils.a`. - `build-jsh-freebsd.ss` stages `jerboa-coreutils` modules and also links `libjsh_coreutils.a`. - `build-jsh-musl.ss` appears closer to the desired state: it explicitly says `jerboa-coreutils` is replaced by Rust uutils and does not compile Scheme coreutils modules. Extras/Android references observed in `vendor/jerboa-shell-extras` after bootstrap: - `vendor/jerboa-shell-extras/Makefile` still defines `COREUTILS ?= $(VENDOR)/jerboa-coreutils/lib`. - `vendor/jerboa-shell-extras/Makefile` still vendors `jerboa-coreutils` in `VENDOR_REPOS` and `LINUX_VENDOR_REPOS`. - `vendor/jerboa-shell-extras/build-jsh-android.sh` sets `COREUTILS_DIR="${COREUTILS_DIR:-${VENDOR}/jerboa-coreutils/lib}"`. - `vendor/jerboa-shell-extras/build-jsh-android.sh` also builds `rust-coreutils/target/release/libjsh_coreutils.a`, so Android is definitely hybrid. - `vendor/jerboa-shell-extras/build-jsh-android.ss` defines `coreutils-dir` as `${vendor-dir}/jerboa-coreutils/lib`. - `vendor/jerboa-shell-extras/build-jsh-android.ss` embeds a long list of `jerboa-coreutils/...` Scheme modules into the Android boot image. - `vendor/jerboa-shell-extras/build-jsh-android.ss` compiles `vendor/jerboa-coreutils/support/libcoreutils.c` into `coreutils-ffi.o`. - The same Android builder also links `libjsh_coreutils.a` with `--whole-archive`. ## Why this matters - It is unclear which implementation actually owns each coreutils command. - The build can accidentally keep depending on stale Scheme modules from `jerboa-coreutils`. - Android boot images become larger and more fragile because they include many `jerboa-coreutils` modules even though Rust coreutils is linked. - Portability fixes may be applied to the wrong implementation. - Release/debugging expectations become misleading: “Rust coreutils” may still require `jerboa-coreutils` to be present. ## Expected direction If Rust coreutils is the intended implementation, the build should converge on: - `rust-coreutils` / `libjsh_coreutils.a` as the only command implementation. - Local `jsh/coreutils` and `jsh/coreutils-shim` wrappers only, if wrappers are still needed. - No `jerboa-coreutils` entry in root or extras vendor dependency lists unless it is truly still required. - No `$(VENDOR)/jerboa-coreutils/lib` in libdirs. - No Android boot embedding of `jerboa-coreutils/...` modules. - No compile of `vendor/jerboa-coreutils/support/libcoreutils.c` if Rust FFI symbols cover the command surface. ## Suggested acceptance criteria 1. Audit every remaining `jerboa-coreutils` reference and classify it as required glue, obsolete wrapper, or stale dependency. 2. Remove stale references from root and extras build files. 3. Ensure macOS, Linux, FreeBSD, and Android builders all use Rust coreutils consistently. 4. Keep the musl builder's Rust-only approach as the model unless a platform-specific reason exists. 5. Add a test or build assertion that selected Rust-coreutils builds do not require `vendor/jerboa-coreutils/lib` for command dispatch. 6. Document any intentionally retained compatibility layer, including why it is still needed and when it can be removed. ## Related context This surfaced while investigating Android/Termux all-features build issues. The Android builder was observed to both build/link `libjsh_coreutils.a` and embed/compile `jerboa-coreutils` Scheme/C support, which contradicts the expectation that coreutils should come from Rust.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ober/jerboa-shell#79

No description provided.

Rows
Columns