Duniter-v2s build with Rust stable?

Nodes Duniter-v2s
1

I am not able to build Duniter v2s with Rust stable (v1.66.1) available on Fedora:

duniter-v2s> cargo build
[…]
   Compiling wasmtime-cache v0.38.3
   Compiling wasmtime v0.38.3
error: failed to run custom build command for `gdev-runtime v3.0.0 (/home/moul/projects/ML/duniter-v2s/runtime/gdev)`

Caused by:
  process didn't exit successfully: `/home/moul/projects/ML/duniter-v2s/target/release/build/gdev-runtime-b664c5228b8de23e/build-script-build` (exit status: 1)
  --- stderr
  Rust nightly not installed, please install it!
warning: build failed, waiting for other jobs to finish...

I am reproducing same error while building the image with the provided Dockerfile:

   Compiling gdev-runtime v3.0.0 (/root/runtime/gdev)
error: failed to run custom build command for `gdev-runtime v3.0.0 (/root/runtime/gdev)`

Caused by:
  process didn't exit successfully: `/root/target/release/build/gdev-runtime-5f73f36b51d8970b/build-script-build` (exit status: 1)
  --- stderr
  Rust nightly not installed, please install it!
warning: build failed, waiting for other jobs to finish...
Error: building at STEP "RUN test -x build/duniter ||     (         CARGO_PROFILE_RELEASE_LTO="true"             cargo build --release -j $threads &&         mkdir -p build &&         mv target/release/duniter build/     )": while running runtime: exit status 101

I do not find what should be changed to allow to build with Rust stable.
I changed in rust-toolchain file channel to stable, but it does not seem to change a thing.
Any idea what could be done?

1 Like
2

Would you mind sharing how you proceed to force Rust stable for the Docker image build?

1 Like
3

You have to use the nightly. It should install automatically the right toolchain according to the rust-toolchain file.

And it’s better to install rustup via rustup.rs than via the distro’s package manager.

Edit: We use the same rust version as Parity to be sure it works correctly (because nightly sometimes has regressions). I think we still use nightly features that are not yet available in stable. (notably for wasm)

1 Like
4

As I understand it this is by design. The error message comes from substrate’s source file utils/wasm-builder/src/prerequisites.rs:

/// Checks that all prerequisites are installed.
///
/// Returns the versioned cargo command on success.
pub(crate) fn check() -> Result<CargoCommandVersioned, String> {
        let cargo_command = crate::get_nightly_cargo();

        if !cargo_command.is_nightly() {
                return Err(print_error_message("Rust nightly not installed, please install it!"))
        }

        check_wasm_toolchain_installed(cargo_command)
}

See there: substrate/prerequisites.rs at duniter-substrate-v0.9.26 · duniter/substrate · GitHub.

2 Likes
5

Probably as mentioned:

Ok, then we have to submit to it. Thanks.

2 Likes
6

In the tutorial, the rustup commands are:

rustup default stable
rustup update nightly
rustup update stable
rustup target add wasm32-unknown-unknown --toolchain nightly

Did you install the correct target for compiling wasm runtime?

my rustup output 
$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/hugo/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-2022-04-20-x86_64-unknown-linux-gnu
nightly-2022-10-09-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.63.0 (4b91a6ea7 2022-08-08)
7

As an exercice I tried to disable the ‘nightly’ requirement. I forked the duniter/substrate repo, made the change, and pushed it into a new branch.

In my local duniter-v2s repo I updated the ‘Cargo.toml’ files accordingly.

But the build fails with:

  error[E0554]: `#![feature]` may not be used on the stable release channel
    --> /usr/local/cargo/git/checkouts/duniter-substrate-0ec28e693220dd60/4f30542/primitives/io/src/lib.rs:22:35
     |
  22 | #![cfg_attr(not(feature = "std"), feature(alloc_error_handler))]
     |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  For more information about this error, try `rustc --explain E0554`.
  error: could not compile `sp-io` due to previous error

The related source file has:

//! I/O host interface for substrate runtime.

#![warn(missing_docs)]
#![cfg_attr(not(feature = "std"), no_std)]
#![cfg_attr(not(feature = "std"), feature(alloc_error_handler))]
#![cfg_attr(
        feature = "std",
        doc = "Substrate runtime standard library as compiled when linked with Rust's standard library."
)]
#![cfg_attr(
        not(feature = "std"),
        doc = "Substrate's runtime standard library as compiled without Rust's standard library."
)]

I guess there is nothing related to a bleeding edge rust nightly release feature, but the chosen syntax is accepted by rust-nightly only.

Is there an alternative syntax that would be accepted by rust-stable? Just curious…

1 Like
8

feature() is for enabling a nightly-only language feature. Here is the tracking issue about this one.

If we switch to stable, we’ll need to rewrite a lot of code, and do it again for each Substrate upgrade… Maybe it’s not even possible yet. I guess Substrate will switch to stable as soon as it contains all the needed features.

Edit: feature(foo) is not the same as cfg(feature="foo") or cfg_attr(feature="foo", [...]) which test a cargo feature defined in the Cargo.toml.

Edit 2: If you want to try further, maybe you can just remove this function.

2 Likes