Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install tools in SDK #35

Open
nastevens opened this issue Apr 5, 2018 · 2 comments
Open

Install tools in SDK #35

nastevens opened this issue Apr 5, 2018 · 2 comments

Comments

@nastevens
Copy link
Member

Right now neither rustc nor cargo are being installed as part of the SDK build - this would probably be quite useful, especially for cross-compiling projects with mixed C/Rust environments.

I made the dumb-simple effort of trying to add BBCLASSEXTEND = "nativesdk" to the recipes, but there were errors from that, so opening this issue to track some more research into the reasons.

@DavidAntliff
Copy link

I'd like to see this too, and I'm currently in a position to help test this, should someone be able to give some pointers on how to go about this.

I've seen mention of TOOLCHAIN_HOST_TASK but I'm not sure what to set it to...

@DavidAntliff
Copy link

DavidAntliff commented Mar 3, 2024

For what it's worth, I was able to get cargo to use the SDK toolchain (created from Yocto Langdale) with commit 019e3b0 of meta-rust-bin.

Prerequisite - have a working meta-rust-bin layer and a recipe using the cargo_bin class.

Set up a Cargo config for the target architecture (I'm building for an ARM / AArch64 CortexA53 CPU):

$ rustup target install target.aarch64-unknown-linux-gnu
$ rustup target add target.aarch64-unknown-linux-gnu

Modify ~/.cargo/config:

[target.aarch64-unknown-linux-gnu]
linker="aarch64-xilinx-linux-gcc"
rustflags = [
    "-C", "link-arg=--sysroot=/path/to/sdk/sysroots/cortexa72-cortexa53-xilinx-linux",
]

To then build with this toolchain, the Yocto environment must be active:

$ source /path/to/sdk/environment-setup-cortexa72-cortexa53-xilinx-linux

To build:

$ cargo build --target=aarch64-unknown-linux-gnu

One thing I haven't yet figured out though is why the binary produced by this (even with the build --release flag) is a good 30% slower in execution time, for a CPU-bounded task, than the one that Yocto builds & deploys when creating the root filesystem image. Perhaps Yocto's release build is more aggressive than the default for cargo's --release flag?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants