[Edited Message Follows] Hi Randy,
I couldn't reproduce the same issue with the latest commits. Below is the issue reproduced on the latest sources: file /usr/include/finclude/math-vector-fortran.h conflicts between attempted installs of lib32-libc6-dev-2.39+git0+6d1e3fb07b-r0.armv7at2hf_neon and libc6-dev-2.39+git0+6d1e3fb07b-r0.cortexa57 So I reverted to older commits and was able to reproduce the issue. Following the commands you provided: ...poky/build > rustc --version rustc 1.72.1 (d5c2e9c34 2023-09-13) (built from a source tarball) ...poky/build > rustc --print=target-list | rg linux | wc -l 70 ...poky/build > rustc --print=target-list | rg linux | head aarch64-linux-android aarch64-unknown-linux-gnu aarch64-unknown-linux-gnu_ilp32 aarch64-unknown-linux-musl aarch64-unknown-linux-ohos aarch64_be-unknown-linux-gnu aarch64_be-unknown-linux-gnu_ilp32 arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf The cargo.sh and rust.sh scripts generated for multilib libraries are identical, except for the file paths, which are different for 32-bit and 64-bit target architectures. This resolves the conflict issue between attempted installs of rust-cross-canadian-arm and rust-cross-canadian-aarch64. I will investigate on it further and inform. Thank you, Deepthi *From:* MacLeod, Randy <[email protected]> *Sent:* Saturday, February 3, 2024 1:46:09 AM *To:* Ross Burton <[email protected]>; Hemraj, Deepthi <[email protected]> *Cc:* OE Core mailing list <[email protected]>; Gowda, Naveen <[email protected]>; Moodalappa, Shivaprasad <[email protected]>; Kokkonda, Sundeep <[email protected]>; [email protected] <[email protected]> *Subject:* Re: [OE-core] [PATCH V3] rust-cross-canadian: Fix file conflicts for arm and aarch64 Add Alex, who might actually be using YP Rust with multilib support. On 2023-12-22 9:40 a.m., Ross Burton wrote: > > On 16 Dec 2023, at 08:56, Hemraj, Deepthi via lists.openembedded.org > <[email protected]> > ( [email protected] ) wrote: > >> The current patch modifies CARGO_ENV_SETUP_SH and RUST_ENV_SETUP_SH macros >> that uses MLPREFIX based on the multilib architecture. >> Hence, creates >> different file names for the environment setup scripts and resolves the >> issue. >> > > This solves the file conflicts if you put a 32-bit and 64-bit rust > cross-compiler into a SDK, but is that actually a usable setup if the > environment scripts are both overwriting the same environment variables? > > Ross I think what Ross is asking is how would we actually use rust in the SDK if we wanted to target different multilibs? The rust compiler , unlike gcc, can actually target multiple target ABIs (x86-64, arm64, x86, arm) using a single binary: Try running one of : ❯ rustc --print=[target-list, target-cpus, target-features] eg on my laptop: ❯ rustc --version rustc 1.71.1 (eb26296b5 2023-08-03) ❯ rustc --print=target-list | rg linux | wc -l 70 ❯ rustc --print=target-list | rg linux | head aarch64-linux-android aarch64-unknown-linux-gnu aarch64-unknown-linux-gnu_ilp32 aarch64-unknown-linux-musl aarch64-unknown-linux-ohos aarch64_be-unknown-linux-gnu aarch64_be-unknown-linux-gnu_ilp32 arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf Please reply to this thread if you have a question or once you have confirmed that theses commands also work in a 32 and 64 bit SDKs from a Yocto build. Furthermore, if you have just one version of Rust, can you (easily) compile, link on the dev box and then copy the executable to a qemu instance and run hello-world for both multilibs. Please show each step to confirm that you are using the SDK version of Rust and then you aren't getting any help (rust or linker) from the host distro. The linker is target specific as shown, for Ubuntu, here: https://medium.com/swlh/compiling-rust-for-raspberry-pi-arm-922b55dbb050 ( https://medium.com/swlh/compiling-rust-for-raspberry-pi-arm-922b55dbb050 ) Does it make sense to have two versions of cargo.sh ? I suspect that it would not but I haven't worked with multlib SDKs very much, at least not recently. Also, I'm not sure off-hand, exactly how we should fix the original bug but maybe we should be adding code that just checks for multilib configuration and 'magically' decides which recipe will provide the Rust compiler and only installs the version of the linker needed or the non-default tune. -- # Randy MacLeod # Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#195251): https://lists.openembedded.org/g/openembedded-core/message/195251 Mute This Topic: https://lists.openembedded.org/mt/103206453/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
