public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Anton Antonov" <anton.antonov@arm.com>
To: openembedded-core@lists.openembedded.org
Subject: rust: conflicts between Yocto and CC-RS compiler parameters
Date: Mon, 24 Oct 2022 10:10:19 -0700	[thread overview]
Message-ID: <Byab.1666631419068358312.NzkU@lists.openembedded.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

Hi all,

After this change (using RUST_HOST_SYS instead of HOST_SYS): https://github.com/yoctoproject/poky/commit/5c45b73c8fa445b5192bb9fac1bc80b038b44c0d builds of parsec-service recipe for qemuarm machine started to fail:
cc1: error: switch '-mcpu=cortex-a15' conflicts with switch '-march=armv7-a+fp' [-Werror]
Full log can be seen here:
https://gitlab.com/akuster/meta-security/-/jobs/3204450989#L2086

This is the cargo build command before the change:
cargo build -v --target arm-poky-linux-gnueabi  
and this is after:
cargo build -v --target armv7-poky-linux-gnueabihf

The problem is that some Rust crates build dependency C libraries using "cc-rs" crate.
This crate adds some compiler parameters depending on target “arch” and for “armv7" these parameters conflicts with compiler parameter defined by Yocto via TUNE_CCARGS:
https://github.com/rust-lang/cc-rs/blob/53fb72c87e5769a299f1886ead831901b9c775d6/src/lib.rs#L1700 We noticed it with qemuarm, but there might be other conflicts as well. (If -Werror is used then builds would fail, otherwise it would be just a warning which is easy to miss)

To fix the issue in our recipe we can define “CRATE_CC_NO_DEFAULTS” env variable which disables adding compiler flags in "cc-rs":
https://github.com/rust-lang/cc-rs#external-configuration-via-environment-variables
So, my questions is: shouldn’t “CRATE_CC_NO_DEFAULTS” be defined in the Rust bbclass instead of expecting that owners of all Rust apps recipes would be aware about this issue for some machines and would add workarounds in their recipes?
I've tried to add "CRATE_CC_NO_DEFAULTS" into rust-target-config.bbclass , but it breaks building rust-native. Looks like we don’t define all the required parameters for native builds and rely (maybe not even intentionally) on parameters defined by cc-rs crate. Therefore to do it properly there should be some logic around defining of "CRATE_CC_NO_DEFAULTS" in rust-target-config.bbclass. I would be happy to hear ideas or recommendations.

Cheers,
Anton

[-- Attachment #2: Type: text/html, Size: 20901 bytes --]

             reply	other threads:[~2022-10-24 17:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 17:10 Anton Antonov [this message]
2022-10-24 19:02 ` [OE-core] rust: conflicts between Yocto and CC-RS compiler parameters Alexander Kanavin
     [not found] ` <17211696138001AA.16920@lists.openembedded.org>
2022-10-24 19:09   ` Alexander Kanavin
2022-10-25 10:56 ` Richard Purdie
2022-10-25 12:22   ` Anton Antonov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Byab.1666631419068358312.NzkU@lists.openembedded.org \
    --to=anton.antonov@arm.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox