rustc 1.71 version needed in jammy to build chromium updates for ARM

[Sebastien Bacher]

The next chromium version is making rustc mandatory to build. Chromium is a snap built from core22 so using the jammy packages, the build is currently failing because it needs libprofiler_builtins.rlib which isn't available.

Upstream provides toolchain builds that can be used but only for amd64 so currently the snap is failing to build on arm
https://launchpad.net/~chromium-team/+snap/chromium-snap-from-source-beta

The version upstream is using is 1.75 but it's possible that a lower version would be enough for now if libprofiler was enabled

[Zixing Liu (liushuyu-011)]

Hi,

I have prepared Rust 1.71 backport with profiler runtime enabled: https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-bpo-1.71/+packages. Can you check if this version can build Chromium 121?

[Nathan Teodosio (nteodosio)]

Thanks for the backport. I launched builds in https://launchpad.net/~nteodosio/+snap/chromium-rust and will report back with the results once available.

[Nathan Teodosio (nteodosio)]

The build failed[1] with

  error: the option `Z` is only accepted on the nightly compiler

In the ideal world that nightly Rustc would be used, but given the nature of deb packaging I suppose it is not doable.

Since I encountered the same error before and was able to overcome it by manually removing all instances of that unstable option from the build files, I'll try that strategy again. It is in general a boring process because those options are generated during build and I couldn't track down their originators; they are not to be found literally in the source files, and so I removed them iteratively with a ad-hoc (and rather embarrassing :p)

--->
find / -type f -name '*.ninja' -exec grep -Fq Zmacro-backtrace {} \; \
-exec sed -i \
  's/-Zdep-info-omit-d-target//g;s/-Zmacro-backtrace//g;s/-Zremap-cwd-prefix=.//g' \
{} +
<---

Additionally, near the end of the build (the one with the old Rustc to be clear) things there were multiple undefined references[2], but I reckon that was because the libprofiler_builtins.rlib was not available and not because of the removal of the -Z options.

I'm submitting another build with the -Z options again removed and will report back with the results once available.

[1] https://launchpadlibrarian.net/709883798/buildlog_snap_ubuntu_jammy_arm64_chromium-rust_BUILDING.txt.gz
[2] https://launchpadlibrarian.net/708915623/buildlog_snap_ubuntu_jammy_armhf_chromium-rust_BUILDING.txt.gz

[Zixing Liu (liushuyu-011)]

> Since I encountered the same error before and was able to overcome it by manually removing all instances of that unstable option from the build files, I'll try that strategy again. It is in general a boring process because those options are generated during build and I couldn't track down their originators; they are not to be found literally in the source files, and so I removed them iteratively with a ad-hoc (and rather embarrassing :p)

You have an easy option here:

There is a somewhat undocumented rustc feature where you could trick it into thinking it is a nightly compiler: just add `RUSTC_BOOTSTRAP: 1` under the `environment` section in your YAML file.

[Nathan Teodosio (nteodosio)]

Thanks for that suggestion, looks like just what I needed.

I looked it up and found this:

 > The build system sets RUSTC_BOOTSTRAP=1. This special variable means
to break the stability guarantees of rust: Allow using #![feature(...)]
with a compiler that's not nightly. This should never be used except
when bootstrapping the compiler.

Is it reasonable to dismiss that foreboding statament on the premise
that we, as downstream, are not the ones introducing the usage of those
unstable features and as such trust upstream to know what they are
doing? I.e., is there an increased risk in using RUSTC_BOOTSTRAP in a
non-nightly compiler (the proposed case for us downstream) in comparison
to using the unstable options in a nightly compiler (what upstream does)?

[Zixing Liu (liushuyu-011)]

> I.e., is there an increased risk in using RUSTC_BOOTSTRAP in a
non-nightly compiler (the proposed case for us downstream) in comparison
to using the unstable options in a nightly compiler (what upstream does)?

Normally, it is not. Rust compilers, even in the stable channel, include the complete logic of a nightly compiler. The logic is disabled by default during the runtime when the compiler is in the stable channel.

The reason why the variable is called "RUSTC_BOOTSTRAP" is that this functionality is usually required when building the next version of the Rust compiler. In this case, the Rust compiler needs to understand newer syntax unavailable in the previous version.

I hope my explanation makes sense.

[Nathan Teodosio (nteodosio)]

 > Normally, it is not. Rust compilers, even in the stable channel, include
 > the complete logic of a nightly compiler. The logic is disabled by
 > default during the runtime when the compiler is in the stable channel.

It is reassuring to learn that.

 > I hope my explanation makes sense.

It does, and thanks again.

[Nathan Teodosio (nteodosio)]

The build with the manual removal of the -Z flags failed[1] with multiple undefined references such as

--->
obj/third_party/rust/cxx/v1/lib/libcxx_lib.rlib(libcxx_lib.cxx.fbfe687f763ab24e-cgu.0.rcgu.o):cxx.fbfe687f763ab24e-cgu.0:function <&T as core::fmt::Debug>::fmt: error: undefined reference to '<str as core::fmt::Debug>::fmt'
obj/third_party/rust/cxx/v1/lib/libcxx_lib.rlib(libcxx_lib.cxx.fbfe687f763ab24e-cgu.0.rcgu.o):cxx.fbfe687f763ab24e-cgu.0:function <&T as core::fmt::Display>::fmt: error: undefined reference to '<str as core::fmt::Display>::fmt'
obj/third_party/rust/cxx/v1/lib/libcxx_lib.rlib(libcxx_lib.cxx.fbfe687f763ab24e-cgu.0.rcgu.o):cxx.fbfe687f763ab24e-cgu.0:function <&T as core::fmt::LowerHex>::fmt: error: undefined reference to 'core::fmt::num::<impl core::fmt::LowerHex for u8>::fmt'
<---

The builds with RUSTC_BOOTSTRAP=1 were silently reset after hours of progress (an old mysterious bug) and therefore we'll find out their actual result only on Monday.

[1] https://launchpadlibrarian.net/710066046/buildlog_snap_ubuntu_jammy_armhf_chromium-rust_BUILDING.txt.gz

[Nathan Teodosio (nteodosio)]

ARMv8 built alright with your proposed RUSTC_BOOTSTRAP strategy.

I still do not understand why manually removing the -Z flags failed.
Could it be that those undefined references were to unstable functions?
But that is just out of curiosity.

For the purposes of this report, please kindly continue with the Jammy
backport of Rustc 1.7.1 as it solves the issue at hand.

[Nathan Teodosio (nteodosio)]

Just for completeness:

> I still do not understand why manually removing the -Z flags failed.

Actually that had failed on the 32-bit ARMv7. ARMv8 had failed because of connection and I didn't care to trigger it again so I assumed it would fail for the same reason.

Turns out that is not the case: ARMv7 just failed again[1] (after 88 h building...) with the same error with the RUSTC_BOOTSTRAP strategy, while ARMv8, as said in last comment, succeeds.

So that is a separate issue.

[1] https://launchpadlibrarian.net/710577930/buildlog_snap_ubuntu_jammy_armhf_chromium-rust_BUILDING.txt.gz

[Zixing Liu (liushuyu-011)]

> Actually that had failed on the 32-bit ARMv7. ARMv8 had failed because of connection and I didn't care to trigger it again so I assumed it would fail for the same reason.

I think it's very difficult to locate the issue, given this log.
The issue looks like two Rust toolchains of different versions were used to compile Chromium/v8.

I suggest building the Chromium using `ninja -v` to see the command line used to invoke the compiler.

[Nathan Teodosio (nteodosio)]

Assigning critical importance as 121 reached stable.