Closed Bug 1710154 Opened 3 years ago Closed 3 years ago fails to build with rust-1.52.0, error: Cannot set `RUSTC_BOOTSTRAP=1


(SeaMonkey :: Build Config, defect)



(Not tracked)



(Reporter: zarniwhoop, Unassigned)


User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Tried to build using a script which worked on the same version when I used patched rustc-1.51.0 earlier this week. Standard 'blfs' instructions as at

Note: we prefer gcc and g++, but that is irrelevant to this rust problem.

Actual results:

First build:
Compiling log v0.4.1
error: Cannot set RUSTC_BOOTSTRAP=1 from build script of encoding_rs v0.8.16.
note: Crates cannot set RUSTC_BOOTSTRAP themselves, as doing so would subvert the stability guarantees of Rust for your project.
help: If you're sure you want to do this in your project, set the environment variable RUSTC_BOOTSTRAP=encoding_rs before running cargo instead.

Second build with 'export RUSTC_BOOTSTRAP=encoding_rs' got further, but similar failure re packed_simd v0.3.4.

Success with 'export RUSTC_BOOTSTRAP=encoding_rs,packed_simd'

Expected results:

I hoped the build would not need any changes, but I'm not surprised.

For the moment I'm content to use those exports, but I guess the code ought to be changed in some way and I'm afraid I have no idea how.

Hope the 'Production' choice for 'Version' is correct.

I wonder why it didn't hit you with 1.51 already. Will be fixed in 2.53.8b1

You can try to apply:

Also you can have more than one toolchain installed so you can try using
rustup default 1.47.0-x86_64-unknown-linux-gnu

Thanks. I've no idea why I didn't hit this with 1.51. I can confirm that after manually applying that patch I did not need to use the envvar.

In my setup I can already use multiple versions of rust (in /opt), this was a fresh system build to look at certain other packages which have caused build breakage in the past, so after getting patched 1.51 to work I wanted to see if the released 1.52 could also build everything.


The backport is from the upcoming 2.53.8b1 queue so should work out of the box here.

Closed: 3 years ago
Resolution: --- → WORKSFORME

I used conventional 'patch' because I wasn't in a git tree. The context in differs - the hunk applies a bit further down the file and CARGO_INCREMENTAL is not mentioned. The usual story with backporting a fix.

You need to log in before you can comment on or make changes to this bug.