> 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
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
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
< as core::fmt::Debug>::fmt: error: undefined reference to
> 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
> 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
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
> 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
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
Thanks for the backport. I launched builds in
https://launchpad.net/~nteodosio/+snap/chromium-rust and will report
back with the results once available.
** Also affects: chromium-browser (Ubuntu)
Importance: Undecided
Status: New
** Changed in: chromium-browser (Ubuntu)
Assignee:
9 matches
Mail list logo
