rust-embedded / meta-rust-bin

Yocto layer for installing Rust toolchain from pre-built binaries
104 stars 63 forks source link

Setting CARGO_BUILD_PROFILE to "debug" results in build error: reserved profile name #167

Closed DavidAntliff closed 6 months ago

DavidAntliff commented 6 months ago

I'm probably using this wrong, but it might indicate an issue.

I have been looking for a way to enable full debugging builds in Yocto (Langdale), with the head of master (019e3b0073510e6f39fac23d9a3c2dd6d793a2fe).

Initially, I tried setting .cargo/config.toml in my project's source root to:

[build]
rustflags = ["-C", "debuginfo=full"]

But for some reason this file is ignored when bitbake builds the recipe.

Instead, I took a look at cargo_bin.class and saw CARGO_BUILD_PROFILE, with a comment that says it can be "release" or "debug", and defaults to "release". Thus, to set debug mode, I have added to my recipe:

CARGO_BUILD_PROFILE = "debug"

However, this now fails to build with this error:

| DEBUG: Executing shell function do_compile
| NOTE: which rustc: [snip]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/my-app/0.1.0-r0/recipe-sysroot-native/usr/bin/rustc
| NOTE: rustc --version rustc 1.76.0 (07dca489a 2024-02-04)
| NOTE: which cargo: [snip]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/my-app/0.1.0-r0/recipe-sysroot-native/usr/bin/cargo
| NOTE: cargo --version cargo 1.76.0 (c84b36747 2024-01-18)
| NOTE: cargo build --verbose --manifest-path [snip]/my-app/Cargo.toml --target=aarch64-unknown-linux-gnu --profile=debug
| error: profile name `debug` is reserved
| To configure the default development profile, use the name `dev` as in [profile.dev]
| See https://doc.rust-lang.org/cargo/reference/profiles.html for more on configuring profiles.

I'm not sure how to proceed.

My full recipe is:

# snip SUMMARY/LICENSE etc

inherit cargo_bin

# Enable network for the compile task allowing cargo to download dependencies
do_compile[network] = "1"

FILESEXTRAPATHS:prepend := "${TOPDIR}/../../apps:"

SRC_URI += " \
    file://my-app/ \
"

S = "${WORKDIR}/my-app"

CARGO_BUILD_PROFILE = "debug"
posborne commented 6 months ago

@DavidAntliff The non-release default profile is named "dev" not "debug", give that a try. https://doc.rust-lang.org/cargo/reference/profiles.html#dev

DavidAntliff commented 6 months ago

@posborne ah, there was a hint of that in my previous error, I didn't think that the default was the debug profile but that makes total sense - thank you.

However, perhaps there's something else missing?

CARGO_BUILD_PROFILE = "dev"

bitbake build now fails:

DEBUG: Executing shell function do_install
ERROR: Cargo found no files to install

If I comment out that CARGO_BUILD_PROFILE it builds properly, as:

/usr/bin/my-app: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=99a2d8f523b317018881d9f8629160596a47e527, for GNU/Linux 3.14.0, with debug_info, not stripped

But it's not really a debug build because if I use gdb with it, I get a lot of optimised-out symbols. The file size is 15 MB though, compared to only 6 MB when I do a cargo build --release locally, so not sure what's going on there.

Sorry, I'm new to meta-rust-bin so I'm probably missing something obvious. Thank you for your patience.

posborne commented 6 months ago

@DavidAntliff Cargo must treat the "dev" profile special in that it uses the "debug" output directory (where in every other case it would use the profile name). I may have to hunt this down in cargo to see if that is the case here (and only in this particular case). You should be able to workaround this by creating a new custom profile that inherits from dev.

posborne commented 6 months ago

Getting back to this, from https://doc.rust-lang.org/cargo/guide/build-cache.html

For historical reasons, the dev and test profiles are stored in the debug directory, and the release and bench profiles are stored in the release directory. User-defined profiles are stored in a directory with the same name as the profile.

I'll update the layer to account for these special cases.

DavidAntliff commented 6 months ago

Thank you, seems to be working now.