| Message ID | icKu.1770116970811561631.kJ0f@lists.yoctoproject.org |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-lts-mixins,scarthgap/rust] | expand |
Thank you for your contribution, Clemens! Here are a few suggestions: Please review the contributor guide [1]. If applicable, this should be merged to recent branches first (e.g. OE-C master) [2][3]. Sign off the patch. Include the patch subject in the mail subject. Include the maintainer(s) in the mailing [4]. Split the mailing into a cover letter and the inline (rather than attached) patch. Here is a recent example: Upstream fix [5] Cover letter [6] Backport-like patch [7] [1] https://docs.yoctoproject.org/dev/contributor-guide/index.html [2] https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#submitting-changes-to-stable-release-branches [3] https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/rust-target-config.bbclass [4] https://git.yoctoproject.org/meta-lts-mixins/about/?h=scarthgap/rust#maintenance [5] https://git.openembedded.org/openembedded-core/commit/meta/recipes-connectivity/openssh/openssh/sshd?id=4e6762f5967b1996cf31ae100fa49e775dfb2866 [6] https://lists.yoctoproject.org/g/yocto-patches/message/3138 [7] https://lists.yoctoproject.org/g/yocto-patches/message/3139 Clayton Casciato
Hi Clayton, thanks for the tips and references! I will learn from them and improve! I will look to submit a bugreport/patch in openembedded-core first. If accepted there, we can look to backport it here. As far as I can see the issue is not fixed there yet as well. Kind regards, Clemens Schlegel
On Thu, 5 Feb 2026, c.schlegel via lists.yoctoproject.org wrote: > Hi Clayton, > > thanks for the tips and references! I will learn from them and improve! > I will look to submit a bugreport/patch in openembedded-core first. If accepted there, we can look to backport it here. > As far as I can see the issue is not fixed there yet as well. The Rust selftests passed for me on qemuarm with latest scarthgap + scarthgap/rust when I tried it yesterday, so it seems like there's also a relevant test missing to catch this. If you can also reproduce with just latest oe-core, getting it fixed on master is definitely the starting point, then we can backport to the mixins. Best regards, Scott
From eaa96e20a509a350685dc89448c1ee9617a41edd Mon Sep 17 00:00:00 2001 From: Clemens Schlegel <c.schlegel@televic.com> Date: Wed, 7 Jan 2026 14:03:23 +0100 Subject: [PATCH] rust-target-config.bbclass: set gcc compile flag in case hf is needed --- classes-recipe/rust-target-config.bbclass | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/classes-recipe/rust-target-config.bbclass b/classes-recipe/rust-target-config.bbclass index 0f1e2e1..9f2aa59 100644 --- a/classes-recipe/rust-target-config.bbclass +++ b/classes-recipe/rust-target-config.bbclass @@ -401,6 +401,10 @@ def rust_gen_target(d, thing, wd, arch): tspec['llvm-floatabi'] = "soft" elif fpu == "hard": tspec['llvm-floatabi'] = "hard" + if "arm" in tspec['llvm-target']: + tspec['pre-link-args'] = { + "gcc": ["-mfloat-abi=hard"] + } tspec['default-uwtable'] = True tspec['dynamic-linking'] = True tspec['executables'] = True -- 2.47.3
Hi, We are using meta-lts-mixins for Rust support in our Yocto image and SDK. Our devices use arm hf. When looking at the resulted toolchain json, we get cat ./x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi/rustlib/armv7-poky-linux-gnueabihf.json { "llvm-target": "armv7-poky-linux-gnueabihf", "data-layout": "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64", "max-atomic-width": 64, "target-pointer-width": "32", "target-c-int-width": 32, "target-endian": "little", "arch": "arm", "os": "linux", "env": "gnu", "vendor": "unknown", "target-family": "unix", "linker": "arm-poky-linux-gnueabi-gcc", "cpu": "generic", "features": "+vfp2,+neon,+v7,+thumb2,+thumb-mode,+a9", "llvm-floatabi": "hard", "dynamic-linking": true, "executables": true, "linker-is-gnu": true, "linker-flavor": "gcc", "has-rpath": true, "has-thread-local": true, "position-independent-executables": true, "panic-strategy": "unwind" } With this it builds, but when running on target there is a linkage issue and resulting in a file not found error when running. After investigating, we think that the gcc flag -mfloat-abi=hard is missing. root@tracs-a9:/tmp# ./test_app -sh: ./test_app: No such file or directory root@tracs-a9:/tmp# ldd test_app linux-vdso.so.1 (0xbeca9000) libc.so.6 => /lib/libc.so.6 (0xb6de0000) /lib/ld-linux.so.3 => /lib/ld-linux-armhf.so.3 (0xb6f5a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6db0000) When adding this, things are fine. ... "llvm-floatabi": "hard", "pre-link-args": { "gcc": [ "-mfloat-abi=hard" ] }, "dynamic-linking": true, ... root@tracs-a9:/tmp# ./test_app Guess the number! Please input your guess. 0 You guessed: 0 Too small! Please input your guess. ^C root@tracs-a9:/tmp# ldd ./test_app linux-vdso.so.1 (0xbed96000) libc.so.6 => /lib/libc.so.6 (0xb6d80000) /lib/ld-linux-armhf.so.3 (0xb6ef8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d50000) root@tracs-a9:/tmp# Attached you find a patch for including this flag in the rust-target-config.bbclass if armhf is detected. Patch ids identical for both Kirkstone/Scarthgap Let me know your thoughts! First time I submit a patch here, so if anything I should do different let me know! Kind regards, Clemens Schlegel