rust: conflicts between Yocto and CC-RS compiler parameters

rust: conflicts between Yocto and CC-RS compiler parameters

[Anton Antonov]

[-- 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 --]

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

[Alexander Kanavin]

On Mon, 24 Oct 2022 at 19:10, Anton Antonov <anton.antonov@arm.com> wrote:

>   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'd suggest you discuss the issue with cc-rs upstream first.
Historically, we don't want components making guesses about
target-specific compiler flags, and end up disabling or overriding
them, so that compiler output is consistent across the whole build.

Alex

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

[Alexander Kanavin]

And yes, seems like we'll have to set CRATE_CC_NO_DEFAULTS globally
and fix any issues that happen because of it.

Alex

On Mon, 24 Oct 2022 at 21:02, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Mon, 24 Oct 2022 at 19:10, Anton Antonov <anton.antonov@arm.com> wrote:
>
> >   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'd suggest you discuss the issue with cc-rs upstream first.
> Historically, we don't want components making guesses about
> target-specific compiler flags, and end up disabling or overriding
> them, so that compiler output is consistent across the whole build.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#172115): https://lists.openembedded.org/g/openembedded-core/message/172115
> Mute This Topic: https://lists.openembedded.org/mt/94539875/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

[Richard Purdie]

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

Re: rust: conflicts between Yocto and CC-RS compiler parameters

[Anton Antonov]

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

On Tue, Oct 25, 2022 at 03:56 AM, Richard Purdie wrote:

> 
> 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 = ""

with CRATE_CC_NO_DEFAULTS defined rustc_driver can't be built for rust-native with an error:

error: linking with `/data/shared/yocto/poky/build/tmp/work/x86_64-linux/rust-native/1.63.0-r0/wrapper/build-rust-ccld` failed: exit status: 1
= note: /data/shared/yocto/poky/build/tmp/hosttools/ld: /data/shared/yocto/poky/build/tmp/work/x86_64-linux/rust-native/1.63.0-r0/rustc-1.63.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_llvm-c2bba4d8034ef27f.rlib(RustWrapper.o): relocation R_X86_64_TPOFF32 against `_ZL9LastError' can not be used when making a shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status

with

CRATE_CC_NO_DEFAULTS:class-target = "true"
CRATE_CC_NO_DEFAULTS:class-nativesdk = "true"

in rust-target-config.bbclass I can successively build native and target recipes.

I've raised an issue to follow this discussion:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14947

Cheers,

Anton

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