Closed Bug 2068826 Opened 2 months ago Closed 1 month ago

Homebrew `rustup` 1.29.0_1 replaced `rustc` symlinks with scripts that don't pass `argv[0]`, breaking `./mach configure`

Categories

(Firefox Build System :: General, defect, P2)

ARM64
macOS
defect

Tracking

(firefox158 fixed)

RESOLVED FIXED
158 Branch
Tracking Status
firefox158 --- fixed

People

(Reporter: mfarrell, Assigned: mfarrell)

References

Details

Attachments

(1 external file)

I've got rustup installed via Homebrew on aarch64-apple-darwin, and rustc installed via rustup. This works correctly outside of Firefox's source tree with regular Rust crates.

I've uninstalled the Homebrew rust package (temporarily installed to install a Rust package from source), and it's not present in my PATH... just rustup's wrappers.

% brew info rustup
==> rustup ✔: stable 1.29.0 (bottled), HEAD [keg-only]
Rust toolchain installer
https://rust-lang.github.io/rustup/
Old Names: rustup-init
Installed (on request)
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/r/rustup.rb
License: Apache-2.0 OR MIT
==> Installed Versions
rustup ✔ 1.29.0_2 (44 files, 11.7MB) [Linked]
==> Options
--HEAD
        Install HEAD version
==> Caveats
To use rustup, ensure you have "$(brew --prefix rustup)/bin" in your $PATH:
  https://rust-lang.github.io/rustup/installation/already-installed-rust.html

This formula no longer provides `rustup-init`.
==> Analytics
install: 10,536 (30 days), 32,580 (90 days), 93,965 (365 days)
install-on-request: 9,773 (30 days), 29,217 (90 days), 82,400 (365 days)
build-error: 4 (30 days)

% which rustup
/opt/homebrew/opt/rustup/bin/rustup
% rustup -V
rustup 1.29.0 (2026-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.98.0 (88d9e12ae 2026-08-18)`

% which rustc 
/opt/homebrew/opt/rustup/bin/rustc
% rustc -V
rustc 1.98.0 (88d9e12ae 2026-08-18)

% which cargo
/opt/homebrew/opt/rustup/bin/cargo
% cargo -V  
cargo 1.98.0 (797e8a9bc 2026-08-05)

In Homebrew rustup 1.28.2 (which I had previously), all binaries (rustc, rustup, etc.) were symlinks to rustup-init.

In 1.29.0_1, https://github.com/Homebrew/homebrew-core/pull/281103 changed these to separate scripts (using bin.env_script_all_files). So they now look like this (1.29.0_2 shown here):

% cat /opt/homebrew/opt/rustup/bin/rustc
#!/bin/bash
RUSTUP_OVERRIDE_UNIX_FALLBACK_SETTINGS="/opt/homebrew/etc/rustup/settings.toml" exec "/opt/homebrew/Cellar/rustup/1.29.0_2/libexec/bin/rustc"  "$@"

These don't work with ./mach configure:

 0:03.34 DEBUG: Executing: `rustup which rustc`
 0:03.34 DEBUG: The command returned non-zero exit status 1.
 0:03.34 DEBUG: Its error output was:
 0:03.34 DEBUG: | error: multiple input filenames provided (first two filenames are `which` and `rustc`)
 0:03.34 DEBUG: |
 0:03.34 ERROR: Command `rustup which rustc` failed with exit status 1.
 0:03.42 E *** Fix above errors and then restart with "./mach build"

build/moz.configure tries to unwrap cargo and rustup into actual binary names. However, from_rustup_which tries to unwrap this by calling prog (absolute path to cargo or rustc) with an argv[0] of rustup:

https://searchfox.org/firefox-main/rev/30d71d4c45a912c6bf7368470e095a695de67c18/build/moz.configure/rust.configure#58-59

If I add a couple of log lines to unwrap_rustup(), this is much clearer:

 0:03.27 unwrapping prog=/opt/homebrew/opt/rustup/bin/rustc, name=rustc, rustup=/opt/homebrew/opt/rustup/bin/rustup
 0:03.32 from_rustup_which: rustup which rustc, prog=/opt/homebrew/opt/rustup/bin/rustc
 0:03.34 DEBUG: Executing: `rustup which rustc`
 0:03.34 DEBUG: The command returned non-zero exit status 1.
 0:03.34 DEBUG: Its error output was:
 0:03.34 DEBUG: | error: multiple input filenames provided (first two filenames are `which` and `rustc`)
 0:03.34 DEBUG: |
 0:03.34 ERROR: Command `rustup which rustc` failed with exit status 1.
 0:03.42 E *** Fix above errors and then restart with "./mach build"

And the output matches calling rustc directly:

% rustc which rustc
error: multiple input filenames provided (first two filenames are `which` and `rustc`)

However, Homebrew's env_script_all_files's generated scripts don't pass argv[0], so this doesn't work anymore.

According to code comments, from_rustup_which's intended behaviour was to fall back to using the wrapper binaries it originally found. But because there's no onerror handler, it just stops there.

I was able to work around this by making the configure script also search for rustup, and then call it when trying to run rustup which {name}, which I'll upload a patch for. I can then get a working build where ./mach rusttests still passes.

But rustup is only a dependency when rustc is installed with Homebrew's wrappers.

At the moment, my system's rustup installation is in a fragile/hacky state to work around this issue, in order to let me still build Firefox.

Edit: identify correct Homebrew PR / version, note about incorrect code comments

Homebrew rustup 1.29 made cargo and rustc no longer symlinks to
rustup-init.

Firefox's build scripts depended on being able to call those "as rustup"
(ie: calling rustc with argv[0] == "rustup", like a multi-call binary),
which no longer works.

So instead, we have to actually resolve the path to rustup.

Summary: Homebrew `rustup` 1.29 removed `rustup-init`, breaking `mach configure` calling `rustc` "as `rustup`" → Homebrew `rustup` 1.29.0_1 replaced `rustc` symlinks with scripts that don't pass `argv[0]`, breaking `./mach configure`
Attachment #9635715 - Attachment description: Bug 2068826 - Call `rustup` for `rustup which {name}` r=ahochheiden → Bug 2068826 - Try calling `rustup` for `rustup which {name}`, and actually fall back to using `PROG` r=ahochheiden
See Also: → 1536486
Pushed by ahochheiden@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/9a0ddbf52501 https://hg.mozilla.org/integration/autoland/rev/846e1bc520ab Try calling `rustup` for `rustup which {name}`, and actually fall back to using `PROG` r=ahochheiden
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 158 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: