On Mon, 2022-10-24 at 10:10 -0700, Anton Antonov wrote: > Hi all, > > After this change (using RUST_HOST_SYS instead of > HOST_SYS): https://github.com/yoctoproject/poky/commit/5c45b73c8fa445 > b5192bb9fac1bc80b038b44c0d 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#L1700We > 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.
I'm a bit worried that we're seeing conflicting flags, it makes me wonder whether we have the right ones in our tune, or, are we mapping between RUST_HOST_SYS and HOST_SYS correctly. I'm guessing this is from "-mfpu=vfpv3-d16" and that we choose a different fpu option? If the difference really is something that rust simply made a different choice on, we should set CRATE_CC_NO_DEFAULTS. rust-native is a bit messy and whilst I would prefer we found out why the flags don't work, I think setting the value for target and probably nativesdk might at least be an improvement: CRATE_CC_NO_DEFAULTS:class-target = "X" CRATE_CC_NO_DEFAULTS:class-nativesdk = "X" or we could just clear it for native: CRATE_CC_NO_DEFAULTS:class-native = "" Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172128): https://lists.openembedded.org/g/openembedded-core/message/172128 Mute This Topic: https://lists.openembedded.org/mt/94539875/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
