On Tue, Dec 7, 2021 at 3:25 PM Wedson Almeida Filho <wedsonaf@xxxxxxxxxx> wrote: > > On Tue, 7 Dec 2021 at 23:21, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > > > On Tue, Dec 7, 2021 at 2:45 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > > > > > On Mon, Dec 6, 2021 at 6:07 AM Miguel Ojeda <ojeda@xxxxxxxxxx> wrote: > > > > > > > > > > ... snip ... > > > > > > Miguel and team, > > > I'm happy to see progress here! Just some quick notes after a first pass. > > > > > > Testing this series applied on mainline, I see: > > > $ make LLVM=1 -j72 defconfig > > > $ grep RUST .config > > > CONFIG_HAS_RUST=y > > > CONFIG_RUSTC_VERSION=14000 > > > # CONFIG_RUST is not set > > > ... > > > $ make LLVM=1 -j72 menuconfig > > > # enable CONFIG_RUST > > > $ make LLVM=1 > > > ... > > > CALL scripts/checksyscalls.sh > > > error: @path is unstable - use -Z unstable-options to enable its use > > > > > > error: @path is unstable - use -Z unstable-options to enable its use > > > $ rustc --version > > > rustc 1.40.0 (73528e339 2019-12-16) > > > > > > Can we update some Kconfig checks to fix that? > > > > After now reading though the Documentation/ patch: > > > > $ rustup update > > $ rustc --version > > rustc 1.57.0 (f1edd0429 2021-11-29) > > $ make LLVM=1 -j72 > > ... > > make[1]: *** No rule to make target > > '/usr/local/google/home/ndesaulniers/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs', > > needed by 'rust/core.o'. Stop. > > Can you run `rustup component add rust-src`? > > When we change the compiler version, we need to install the source > code for `core` for the new version. (We'll update the documentation > to reflect that.) Cool, yeah please add that to the docs. Kconfig checks should be added to make this idiot-proof; starting from everything uninstalled, I should be able to read the Kconfig dependencies in `make menuconfig` to understand what I'm missing. And if I'm missing anything, I shouldn't be able to select CONFIG_RUST. I get slightly further now. $ make LLVM=1 -j72 ... BINDGEN rust/bindings_helpers_generated.rs thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "could not run executable `/android0/llvm-project/clang`: Permission denied (os error 13)"', /usr/local/google/home/ndesaulniers/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-1.3.0/src/support.rs:196:58 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "could not run executable `/android0/llvm-project/clang`: Permission denied (os error 13)"', /usr/local/google/home/ndesaulniers/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-1.3.0/src/support.rs:196:58 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace make[1]: *** [rust/Makefile:261: rust/bindings_helpers_generated.rs] Error 1 make[1]: *** Deleting file 'rust/bindings_helpers_generated.rs' make[1]: *** Waiting for unfinished jobs.... make[1]: *** [rust/Makefile:248: rust/bindings_generated.rs] Error 1 make[1]: *** Deleting file 'rust/bindings_generated.rs' make: *** [Makefile:1271: prepare0] Error 2 It looks like bindgen found part of the path to llvm-project that I have checked out to disk for when I do development on LLVM for work. So this might only be an issue if folks have a copy of clang built from source in their $PATH? $ which clang /android0/llvm-project/llvm/build/bin/clang Looking at the output of `make LLVM=1 -j72 V=1`, I see two invocations of bindgen, and can repro if I just run the full command manually. I don't see my path to my source code checkout of llvm-project in the command line invocation of bindgen; this might be an issue itself with bindgen. Googling for "could not run executable" and bindgen, I find this thread with a similar failure string: https://bugzilla.mozilla.org/show_bug.cgi?id=1363655 No hits in their issue tracker: https://github.com/rust-lang/rust-bindgen. $ bindgen --version bindgen 0.59.2 $ cargo install --locked --version 0.56.0 bindgen $ bindgen --version bindgen 0.56.0 $ make LLVM=1 -j72 # produces the same error. I guess the error is coming not from bindgen, but a dependency of its; "clang-sys?" https://github.com/KyleMayes/clang-sys/blob/master/src/support.rs I've filed an issue in https://github.com/KyleMayes/clang-sys/issues/138; let's follow up there? -- Thanks, ~Nick Desaulniers
