nativesdk support

[sstncr]

Version(s) of meta-rust

master branch, 0621067

Version(s) of poky and/or oe-core

poky 2.6.1, thud branch

Expected result

rust is in the SDK and can be used to compile rust applications with the standard sdk, built with bitbake -c populate_sdk

Actual result

meta-rust does not have support for nativesdk

[sstncr]

I'm using rust for a personal project with Yocto, and I was very happy to see that meta-rust exists and adds support for building rust apps with my image.
However, SDK support will be very nice and I've attempted adding support here #237
But I'm getting stuck at this error:

COMPILE nativesdk-rust build
| running: /home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rust-snapshot/bin/cargo build --manifest-path /home/vagrant/z/build/tmp/work/x86_64-nati
vesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rustc-1.33.0-src/src/bootstrap/Cargo.toml --frozen
|    Compiling proc-macro2 v0.4.24
|    Compiling unicode-xid v0.1.0
|    Compiling libc v0.2.46
|    Compiling serde v1.0.82
|    Compiling ryu v0.2.7
|    Compiling itoa v0.4.3
|    Compiling fixedbitset v0.1.9
|    Compiling cc v1.0.28
|    Compiling cfg-if v0.1.6
|    Compiling ordermap v0.3.5
|    Compiling lazy_static v0.2.11
|    Compiling getopts v0.2.17
|    Compiling build_helper v0.1.0 (/home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rustc-1.33.0-src/src/build_helper)                            
|    Compiling petgraph v0.4.13
|    Compiling filetime v0.2.4
|    Compiling num_cpus v1.8.0
|    Compiling time v0.1.40
|    Compiling cmake v0.1.33
|    Compiling quote v0.6.10
|    Compiling syn v0.15.22
|    Compiling serde_derive v1.0.81
|    Compiling serde_json v1.0.33
|    Compiling toml v0.4.10
|    Compiling bootstrap v0.0.0 (/home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rustc-1.33.0-src/src/bootstrap)                                  
|     Finished dev [unoptimized] target(s) in 2m 07s
| running: /home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rustc-1.33.0-src/build/bootstrap/debug/bootstrap build --verbose                       
|
|
| failed to execute command: "/home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/recipe-sysroot/opt/poky/2.6.1/sysroots/x86_64-pokysdk-linux/usr/lib/llvm-rust/bin/llvm-config" "--bindir"
| error: No such file or directory (os error 2)
|
|
| Traceback (most recent call last):
|   File "src/bootstrap/bootstrap.py", line 860, in <module>
|     main()
|   File "src/bootstrap/bootstrap.py", line 843, in main
|     bootstrap(help_triggered)
|   File "src/bootstrap/bootstrap.py", line 829, in bootstrap
|     run(args, env=env, verbose=build.verbose)
|   File "src/bootstrap/bootstrap.py", line 141, in run
|     raise RuntimeError(err)
| RuntimeError: failed to run: /home/vagrant/z/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-rust/1.33.0-r0/rustc-1.33.0-src/build/bootstrap/debug

llvm-config does exist at that path, but it seems it can't be run and I'm a bit confused where the problem is.
Any pointer, help, ideas is greatly appreciated.

[tranzmatt]

Has there been any update on this? I'm having the same problem.

[srwalter]

Usually a strange "file not found" error is related to shared objects. Either a necessary shared object can't be found, or else the interpreter (i.e. ld-linux.so.2) can't be found. You can use readelf to dump the paths to those things and see which is the case. I thought that bitbake was supposed to fix those things up for SDK's, however

[cmcqueen]

I am also surprised to discover the SDK doesn't have rustc and cargo in it.

I suppose an alternative workflow for manual compiles is to do

bitbake my-rust-app -c devshell

But, doing this, I find that which cargo finds /home/craigm/.cargo/bin/cargo (of my local native rust installation) instead of the expected /home/craigm/yocto/poky/build/tmp/work/aarch64-poky-linux/my-rust-app/123-r0/recipe-sysroot-native/usr/bin/cargo.

But, if I examine the build logs for my-rust-app, in /home/craigm/yocto/poky/build/tmp/work/aarch64-poky-linux/my-rust-app/123-r0/temp/log.do_compile it does show the correct path to cargo for cross-compilation.

Is there something that I'm missing about using -c devshell for rust also? Is this in any way related to SDK support?

[cmcqueen]

In the -c devshell case, I wonder if it's because:

• .profile and .bashrc contain
  source "$HOME/.cargo/env"
• .cargo/env contains
  # Prepending path in case a system-installed rustc needs to be overridden
export PATH="$HOME/.cargo/bin:$PATH"

In .profile and .bashrc I've changed:

source "$HOME/.cargo/env"

to:

if [ -z "$BBPATH" ] ; then
    source "$HOME/.cargo/env"
fi

and that allows -c devshell to find the right cargo.

[rwmacleod]

There is a pull request open to add SDK support. It works on released branches I'm told but didn't work on the master branch as of ~2 weeks ago due to a linking problems with glibc-2.33.
See:
#313

I'll be looking into it some time in April or worst case, May.

[cmcqueen]

Is there a well-defined workflow for doing manual cross-compiles by some other method, eg

bitbake my-rust-app -c devshell

[rwmacleod]

Not that I'm aware of.
You can however use the rustup toolchain and another linker:

$ sudo apt install gcc-9-aarch64-linux-gnu
$ rustup target add aarch64-unknown-linux-gnu
$ cat ~/.cargo/config
[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc-9"
$ cargo build --target=aarch64-unknown-linux-gnu
   Compiling hello-cargo v0.1.0 (hello-cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 1.44s
$ file target/aarch64-unknown-linux-gnu/debug/hello-cargo
 ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), ...

# copy to Rpi4/64bit
rpi4 $ /tmp/hello-cargo
Hello, world!

One could also get the linker from the Yocto SDK but I haven't tried that. Maybe we should continue this discussion on the yocto email list rather than on this thread.

[DavidAntliff]

@rwmacleod was this conversation continued on the Yocto email list? If so, do you have a link to the email archive, please?

---

$ rustup target add aarch64-unknown-linux-gnu

One may need to do install as well:

$ rustup target install aarch64-unknown-linux-gnu

Or you may get errors like:

error[E0463]: can't find crate for `core`
  |
  = note: the `aarch64-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add aarch64-unknown-linux-gnu`

I'm not sure if rustup target add should automatically include install, but for me it did not, and I had to work out that 'rust-std' for 'aarch64-unknown-linux-gnu' wasn't actually installed.

[DavidAntliff]

I realise it's for an entirely different layer, but if it helps anyone, I was able to use the advice in this thread to configure cargo to use the rust toolchain in a Yocto SDK, and I think the steps would be much the same for meta-rust: rust-embedded/meta-rust-bin#35

Unfortunately, as I am using Yocto Langdale, I cannot use meta-rust.