Re: [OE-core] rust: conflicts between Yocto and CC-RS compiler parameters

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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