[PATCH 1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS

[PATCH 1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS

[Khem Raj]

BUILD_LDFLAGS is used by other recipes to emit native LDFLAGS
into their cmake toolchain files especially in QT layers. it
will usually be inherited by recipes wanting clang provide
BUILD_* variables so this is more appropriate than LDFLAGS to
pass these options.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/classes/toolchain/clang-native.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/toolchain/clang-native.bbclass b/meta/classes/toolchain/clang-native.bbclass
index 4de491a1cb5..006be9fadd6 100644
--- a/meta/classes/toolchain/clang-native.bbclass
+++ b/meta/classes/toolchain/clang-native.bbclass
@@ -15,4 +15,4 @@ BUILD_READELF = "${BUILD_PREFIX}llvm-readelf"
 
 DEPENDS += "clang-native libcxx-native compiler-rt-native"
 
-LDFLAGS += " --rtlib=libgcc --unwindlib=libgcc"
+BUILD_LDFLAGS += " --rtlib=libgcc --unwindlib=libgcc"

[PATCH 2/7] cargo-c: Update patches to latest versions

[Khem Raj]

getrandom patch is accepted upstream with minor changes
parking_lot patch has addressed upstream feedback

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...Use-libc-SYS_futex_time64-on-riscv32.patch | 69 +++++++------------
 ...Use-libc-SYS_futex_time64-on-riscv32.patch | 65 +++++++----------
 2 files changed, 51 insertions(+), 83 deletions(-)

diff --git a/meta/recipes-devtools/rust/cargo-c/0001-getrandom-Use-libc-SYS_futex_time64-on-riscv32.patch b/meta/recipes-devtools/rust/cargo-c/0001-getrandom-Use-libc-SYS_futex_time64-on-riscv32.patch
index dc7130fb574..638832c467f 100644
--- a/meta/recipes-devtools/rust/cargo-c/0001-getrandom-Use-libc-SYS_futex_time64-on-riscv32.patch
+++ b/meta/recipes-devtools/rust/cargo-c/0001-getrandom-Use-libc-SYS_futex_time64-on-riscv32.patch
@@ -1,53 +1,36 @@
 From 71c356a07fbbf1530cfc87960e975f93bc9007e8 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Tue, 22 Jul 2025 09:46:03 -0700
-Subject: [PATCH] Use libc::SYS_futex_time64 on riscv32
+Subject: [PATCH] Use getrandom syscall on riscv32/riscv64 linux
 
-On RISC-V 32-bit (riscv32), the SYS_futex system call is
-often handled indirectly due to the use of a 64-bit time_t
-type. Specifically, while SYS_futex is not directly defined,
-a related syscall like SYS_futex_time64 can be used,
+Minimum kernel needed on RISCV is fairly new (4.15+) so we are sure
+to have getrandom syscall, on glibc there is mimimal ABI kernel to denote
+it but musl does not have any other way to indicate it, so add it
+as a condition here to choose getrandom backend for rv32/rv64 on linux
+when using musl.
 
-Upstream-Status: Submitted [https://github.com/rust-random/getrandom/pull/698]
+Upstream-Status: Backport [https://github.com/rust-random/getrandom/pull/699]
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
 ---
  src/backends/use_file.rs | 17 +++++++++++++++++
  1 file changed, 17 insertions(+)
 
-diff --git a/src/backends/use_file.rs b/src/backends/use_file.rs
-index 7b48d43..baa0c66 100644
---- a/src/backends/use_file.rs
-+++ b/src/backends/use_file.rs
-@@ -158,7 +158,18 @@ mod sync {
-     pub(super) fn wait() {
-         let op = libc::FUTEX_WAIT | libc::FUTEX_PRIVATE_FLAG;
-         let timeout_ptr = core::ptr::null::<libc::timespec>();
-+        #[cfg(not(target_arch = "riscv32"))]
-         let ret = unsafe { libc::syscall(libc::SYS_futex, &FD, op, FD_ONGOING_INIT, timeout_ptr) };
-+        #[cfg(target_arch = "riscv32")]
-+        let ret = unsafe {
-+            libc::syscall(
-+                libc::SYS_futex_time64,
-+                &FD,
-+                op,
-+                FD_ONGOING_INIT,
-+                timeout_ptr,
-+            )
-+        };
-         // FUTEX_WAIT should return either 0 or EAGAIN error
-         debug_assert!({
-             match ret {
-@@ -172,7 +183,13 @@ mod sync {
-     /// Wake up all threads which wait for value of atomic `FD` to change.
-     pub(super) fn wake() {
-         let op = libc::FUTEX_WAKE | libc::FUTEX_PRIVATE_FLAG;
-+
-+        #[cfg(not(target_arch = "riscv32"))]
-         let ret = unsafe { libc::syscall(libc::SYS_futex, &FD, op, libc::INT_MAX) };
-+
-+        #[cfg(target_arch = "riscv32")]
-+        let ret = unsafe { libc::syscall(libc::SYS_futex_time64, &FD, op, libc::INT_MAX) };
-+
-         debug_assert!(ret >= 0);
-     }
- 
+--- a/src/backends.rs
++++ b/src/backends.rs
+@@ -93,7 +93,15 @@ cfg_if! {
+                 // Minimum supported Linux kernel version for MUSL targets
+                 // is not specified explicitly (as of Rust 1.77) and they
+                 // are used in practice to target pre-3.17 kernels.
+-                target_env = "musl",
++                all(
++                    target_env = "musl",
++                    not(
++                        any(
++                            target_arch = "riscv64",
++                            target_arch = "riscv32",
++                        ),
++                    ),
++                ),
+             ),
+         )
+     ))] {
diff --git a/meta/recipes-devtools/rust/cargo-c/0001-parking-lot-Use-libc-SYS_futex_time64-on-riscv32.patch b/meta/recipes-devtools/rust/cargo-c/0001-parking-lot-Use-libc-SYS_futex_time64-on-riscv32.patch
index 37f21af3d14..9e84ca3ec79 100644
--- a/meta/recipes-devtools/rust/cargo-c/0001-parking-lot-Use-libc-SYS_futex_time64-on-riscv32.patch
+++ b/meta/recipes-devtools/rust/cargo-c/0001-parking-lot-Use-libc-SYS_futex_time64-on-riscv32.patch
@@ -1,66 +1,51 @@
-From 78d4c37e9c5b60ea2368627c2fc297dfc46bec2a Mon Sep 17 00:00:00 2001
+From 7ebddca7070742bbb9cce471a93d699ad70ee371 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Tue, 22 Jul 2025 10:15:06 -0700
-Subject: [PATCH] Use libc::SYS_futex_time64 on riscv32
+Subject: [PATCH] Use libc::SYS_futex_time64 on riscv32/musl
 
 On RISC-V 32-bit (riscv32), the SYS_futex system call is
 often handled indirectly due to the use of a 64-bit time_t
 type. Specifically, while SYS_futex is not directly defined,
-a related syscall like SYS_futex_time64 can be used,
+a related syscall like SYS_futex_time64 can be used on target
+e.g. riscv32
 
 Upstream-Status: Submitted [https://github.com/Amanieu/parking_lot/pull/485]
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
 ---
- src/thread_parker/linux.rs | 19 +++++++++++++++++++
- 1 file changed, 19 insertions(+)
+ src/thread_parker/linux.rs | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/src/thread_parker/linux.rs b/src/thread_parker/linux.rs
-index 92601f6..3695624 100644
+index 92601f6..0952db4 100644
 --- a/src/thread_parker/linux.rs
 +++ b/src/thread_parker/linux.rs
-@@ -108,6 +108,7 @@ impl ThreadParker {
+@@ -108,9 +108,13 @@ impl ThreadParker {
              .as_ref()
              .map(|ts_ref| ts_ref as *const _)
              .unwrap_or(ptr::null());
-+        #[cfg(not(target_arch = "riscv32"))]
++        #[cfg(not(all(target_arch = "riscv32", target_env = "musl")))]
++        let futex_num = libc::SYS_futex;
++        #[cfg(all(target_arch = "riscv32", target_env = "musl",))]
++        let futex_num = libc::SYS_futex_time64;
          let r = unsafe {
              libc::syscall(
-                 libc::SYS_futex,
-@@ -117,6 +118,16 @@ impl ThreadParker {
-                 ts_ptr,
-             )
-         };
-+        #[cfg(target_arch = "riscv32")]
-+        let r = unsafe {
-+            libc::syscall(
-+                libc::SYS_futex_time64,
-+                &self.futex,
-+                libc::FUTEX_WAIT | libc::FUTEX_PRIVATE_FLAG,
-+                1,
-+                ts_ptr,
-+            )
-+        };
-         debug_assert!(r == 0 || r == -1);
-         if r == -1 {
-             debug_assert!(
-@@ -137,12 +148,20 @@ impl super::UnparkHandleT for UnparkHandle {
+-                libc::SYS_futex,
++                futex_num,
+                 &self.futex,
+                 libc::FUTEX_WAIT | libc::FUTEX_PRIVATE_FLAG,
+                 1,
+@@ -137,8 +141,13 @@ impl super::UnparkHandleT for UnparkHandle {
      unsafe fn unpark(self) {
          // The thread data may have been freed at this point, but it doesn't
          // matter since the syscall will just return EFAULT in that case.
-+        #[cfg(not(target_arch = "riscv32"))]
++        #[cfg(not(all(target_arch = "riscv32", target_env = "musl",)))]
++        let futex_num = libc::SYS_futex;
++        #[cfg(all(target_arch = "riscv32", target_env = "musl",))]
++        let futex_num = libc::SYS_futex_time64;
++
          let r = libc::syscall(
-             libc::SYS_futex,
+-            libc::SYS_futex,
++            futex_num,
              self.futex,
              libc::FUTEX_WAKE | libc::FUTEX_PRIVATE_FLAG,
              1,
-         );
-+        #[cfg(target_arch = "riscv32")]
-+        let r = libc::syscall(
-+            libc::SYS_futex_time64,
-+            self.futex,
-+            libc::FUTEX_WAKE | libc::FUTEX_PRIVATE_FLAG,
-+            1,
-+        );
-         debug_assert!(r == 0 || r == 1 || r == -1);
-         if r == -1 {
-             debug_assert_eq!(errno(), libc::EFAULT);

[PATCH 3/7] libxcrypt: Allow undefined symbols in version scripts with lld linker

[Khem Raj]

Unlike GNU ld, LLD defaults to erroring about undefined version symbols
add commandline parameter to sush lld here

Fixes
| x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined
| x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined
| x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined
| x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined
| x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined
| x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-core/libxcrypt/libxcrypt.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc
index 77fec832348..10f6cd921d8 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.inc
+++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
@@ -24,3 +24,5 @@ API = "--disable-obsolete-api"
 EXTRA_OECONF += "${API}"
 
 BBCLASSEXTEND = "native nativesdk"
+
+LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}"

Re: [OE-core] [PATCH 3/7] libxcrypt: Allow undefined symbols in version scripts with lld linker

[Alexander Kanavin]

On Fri, 1 Aug 2025 at 06:22, Khem Raj via lists.openembedded.org
<raj.khem=gmail.com@lists.openembedded.org> wrote:
>
> Unlike GNU ld, LLD defaults to erroring about undefined version symbols
> add commandline parameter to sush lld here
>
> Fixes
> | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined
> | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined
> | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined
> | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined
> | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined
> | x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation)

> +LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}"

Wait. Why is there an undefined symbol error in the first place?
Shouldn't we address the error, rather than silence it?

The same question stands for similar patches for libtirpc, gzip and
binutils-cross-canadian.

Alex

Re: [OE-core] [PATCH 3/7] libxcrypt: Allow undefined symbols in version scripts with lld linker

[Khem Raj]

On Thu, Aug 7, 2025 at 2:57 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Fri, 1 Aug 2025 at 06:22, Khem Raj via lists.openembedded.org
> <raj.khem=gmail.com@lists.openembedded.org> wrote:
> >
> > Unlike GNU ld, LLD defaults to erroring about undefined version symbols
> > add commandline parameter to sush lld here
> >
> > Fixes
> > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'crypt_gensalt_r' failed: symbol not defined
> > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt' failed: symbol not defined
> > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt' failed: symbol not defined
> > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_gensalt_r' failed: symbol not defined
> > | x86_64-yoesdk-linux-ld.lld: error: version script assignment of 'XCRYPT_2.0' to symbol 'xcrypt_r' failed: symbol not defined
> > | x86_64-yoesdk-linux-clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> > +LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}"
>
> Wait. Why is there an undefined symbol error in the first place?
> Shouldn't we address the error, rather than silence it?

LLD has stricter defaults and strict symbol versioning enforcement.
LLD requires that all symbols
referenced in version scripts actually exist in the object files being
linked Same errors/behavior can be
seen with GNU linker as well if we add -Wl,--undefined-version to LDFLAGS
GNU linker chooses to be a bit lenient with defaults. It is a common
pattern with new vs old tools.

libxcrypt uses version scripts to manage symbol versioning, but LLD
requires that all symbols referenced
in version scripts actually exist in the object files being linked.
The symbols might be:

- Conditionally compiled out based on configuration
- Defined with different names/prefixes
- Missing due to build configuration issues

Having LLD to lower its barrier does not change the output it
produces, it's the same as GNU ld,
There is no difference - both .so files work identically at runtime
since the symbols are exported into .dynstr sections so old binaries
needing these versioned symbols can still
link to them at runtime.

Should the version script be fixed ? maybe, I am not sure where all
libxcypt is used in legacy systems
to qualify this. Current assumption is to have these symbols. This
patch makes LLD behave like GNU LD
does.

Hope this helps you understand what's going on. Feel free to ask if
you have more doubts.

>
> The same question stands for similar patches for libtirpc, gzip and
> binutils-cross-canadian.

They all have the same issue underneath.

>
> Alex

Re: [OE-core] [PATCH 3/7] libxcrypt: Allow undefined symbols in version scripts with lld linker

[Alexander Kanavin]

On Thu, 7 Aug 2025 at 22:18, Khem Raj <raj.khem@gmail.com> wrote:

> Hope this helps you understand what's going on. Feel free to ask if
> you have more doubts.
>
> >
> > The same question stands for similar patches for libtirpc, gzip and
> > binutils-cross-canadian.
>
> They all have the same issue underneath.

The way you describe it, this at least merits upstream tickets, if not
actual fixes. Upstreams can then decide if lld is something they care
about.

Alex

Re: [OE-core] [PATCH 3/7] libxcrypt: Allow undefined symbols in version scripts with lld linker

[Khem Raj]

On Mon, Aug 11, 2025 at 1:18 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Thu, 7 Aug 2025 at 22:18, Khem Raj <raj.khem@gmail.com> wrote:
>
> > Hope this helps you understand what's going on. Feel free to ask if
> > you have more doubts.
> >
> > >
> > > The same question stands for similar patches for libtirpc, gzip and
> > > binutils-cross-canadian.
> >
> > They all have the same issue underneath.
>
> The way you describe it, this at least merits upstream tickets, if not
> actual fixes. Upstreams can then decide if lld is something they care
> about.
>

Its in plan.
I have reported it for libxcrypt.

https://github.com/besser82/libxcrypt/issues/213

Others are also in works.
> Alex

[PATCH 4/7] libtirpc: Allow undefined symbols in version scripts with lld linker

[Khem Raj]

Fixes link errors with lld

aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol '_svcauth_gss' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'authgss_create' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'authgss_create_default' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'authgss_free_private_data' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'authgss_get_private_data' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'authgss_service' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'cbc_crypt' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'ecb_crypt' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'endrpcent' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'getrpcent' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'getrpcbynumber' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'getrpcbyname' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'gss_log_debug' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'gss_log_hexdump' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'gss_log_status' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'rpc_gss_get_error' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'rpc_gss_get_mech_info' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'rpc_gss_get_mechanisms' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'rpc_gss_get_principal_name' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'TIRPC_0.3.0' to symbol 'rpc_gss_get_versions' failed: symbol not defined

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-extended/libtirpc/libtirpc_1.3.6.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/libtirpc/libtirpc_1.3.6.bb b/meta/recipes-extended/libtirpc/libtirpc_1.3.6.bb
index 6ea9a725dbf..98bb1128c00 100644
--- a/meta/recipes-extended/libtirpc/libtirpc_1.3.6.bb
+++ b/meta/recipes-extended/libtirpc/libtirpc_1.3.6.bb
@@ -27,6 +27,8 @@ PACKAGECONFIG ??= "\
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6"
 PACKAGECONFIG[gssapi] = "--enable-gssapi,--disable-gssapi,krb5"
 
+LDFLAGS:append:toolchain-clang = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld', ' -Wl,--undefined-version', '', d)}"
+
 do_install:append() {
 	test -e ${D}${sysconfdir}/netconfig && chown root:root ${D}${sysconfdir}/netconfig
 }

[PATCH 5/7] gzip: Always use GNU ld for linking

[Khem Raj]

Linking does not yet work with LLD

Fixes
aarch64-yoesdk-linux-ld.lld: error: undefined symbol: gzopen
>>> referenced by minigzip.c
>>>               minigzip.o:(main)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-core/zlib/zlib_1.3.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/zlib/zlib_1.3.1.bb b/meta/recipes-core/zlib/zlib_1.3.1.bb
index e62c50c5df7..96b7a5821ff 100644
--- a/meta/recipes-core/zlib/zlib_1.3.1.bb
+++ b/meta/recipes-core/zlib/zlib_1.3.1.bb
@@ -20,6 +20,7 @@ SRC_URI[sha256sum] = "9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b
 PREMIRRORS:append = " https://zlib.net/ https://zlib.net/fossils/"
 
 CFLAGS += "-D_REENTRANT -fPIE"
+LDFLAGS:append = " -fuse-ld=bfd"
 
 RDEPENDS:${PN}-ptest += "make"
 

Re: [OE-core] [PATCH 5/7] gzip: Always use GNU ld for linking

[Randy MacLeod]

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

On 2025-08-01 12:22 a.m., Khem Raj via lists.openembedded.org wrote:
> Linking does not yet work with LLD
>
> Fixes
> aarch64-yoesdk-linux-ld.lld: error: undefined symbol: gzopen
>>>> referenced by minigzip.c
>>>>                minigzip.o:(main)
Do we need minigzip?
Does upstream know about the bug?
../Randy
> Signed-off-by: Khem Raj<raj.khem@gmail.com>
> ---
>   meta/recipes-core/zlib/zlib_1.3.1.bb | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/zlib/zlib_1.3.1.bb b/meta/recipes-core/zlib/zlib_1.3.1.bb
> index e62c50c5df7..96b7a5821ff 100644
> --- a/meta/recipes-core/zlib/zlib_1.3.1.bb
> +++ b/meta/recipes-core/zlib/zlib_1.3.1.bb
> @@ -20,6 +20,7 @@ SRC_URI[sha256sum] = "9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b
>   PREMIRRORS:append =" https://zlib.net/ https://zlib.net/fossils/"
>   
>   CFLAGS += "-D_REENTRANT -fPIE"
> +LDFLAGS:append = " -fuse-ld=bfd"
>   
>   RDEPENDS:${PN}-ptest += "make"
>   
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#221217):https://lists.openembedded.org/g/openembedded-core/message/221217
> Mute This Topic:https://lists.openembedded.org/mt/114479323/3616765
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
# Randy MacLeod
# Wind River Linux

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

[PATCH 6/7] binutils-cross-canadian: Always use GNU linker

[Khem Raj]

LLD fails to link gprofng
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'dlclose' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'dlopen' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'fclose' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'fdopen' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'fgetpos' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'fopen' failed: symbol not defined
aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'fsetpos' failed: symbol not defined

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/binutils/binutils-cross-canadian.inc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
index c1fda1a4658..7d7ffe92ce1 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
@@ -13,6 +13,11 @@ EXTRA_OECONF += "--with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VEND
 # e.g. we switch between different machines with different tunes.
 EXTRA_OECONF[vardepsexclude] = "TUNE_PKGARCH"
 
+# lld complains
+# aarch64-yoesdk-linux-ld.lld: error: version script assignment of 'GLIBC_2.0' to symbol 'dlclose' failed: symbol not defined
+
+LDFLAGS:append:toolchain-clang = " -fuse-ld=bfd"
+
 do_install () {
 	autotools_do_install
 

[PATCH 7/7] fmt: Fix build with clang-21

[Khem Raj]

Backport a fix from upstream master branch

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...compilation-on-clang-21-libc-21-4477.patch | 46 +++++++++++++++++++
 meta/recipes-devtools/fmt/fmt_11.2.0.bb       |  4 +-
 2 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/fmt/fmt/0001-Fix-compilation-on-clang-21-libc-21-4477.patch

diff --git a/meta/recipes-devtools/fmt/fmt/0001-Fix-compilation-on-clang-21-libc-21-4477.patch b/meta/recipes-devtools/fmt/fmt/0001-Fix-compilation-on-clang-21-libc-21-4477.patch
new file mode 100644
index 00000000000..911fa90a40c
--- /dev/null
+++ b/meta/recipes-devtools/fmt/fmt/0001-Fix-compilation-on-clang-21-libc-21-4477.patch
@@ -0,0 +1,46 @@
+From f4345467fce7edbc6b36c3fa1cf197a67be617e2 Mon Sep 17 00:00:00 2001
+From: Remy Jette <remy@remyjette.com>
+Date: Sat, 21 Jun 2025 07:28:14 -0700
+Subject: [PATCH] Fix compilation on clang-21 / libc++-21 (#4477)
+
+`<cstdlib>` was not being included, so malloc and free were only declared
+via transitive includes. Some includes changed in the latest libc++-21
+build which broke fmt.
+
+Also changed `malloc`/`free` to `std::malloc` and `std::free`, as
+putting those symbols in the global namespace is optional for the
+implementation when including `<cstdlib>`.
+
+Upstream-Status: Backport [https://github.com/fmtlib/fmt/pull/4477]
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ include/fmt/format.h | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+Index: fmt-11.2.0/include/fmt/format.h
+===================================================================
+--- fmt-11.2.0.orig/include/fmt/format.h
++++ fmt-11.2.0/include/fmt/format.h
+@@ -44,6 +44,7 @@
+ #  include <cmath>    // std::signbit
+ #  include <cstddef>  // std::byte
+ #  include <cstdint>  // uint32_t
++#  include <cstdlib>  // std::malloc, std::free
+ #  include <cstring>  // std::memcpy
+ #  include <limits>   // std::numeric_limits
+ #  include <new>      // std::bad_alloc
+@@ -744,12 +745,12 @@ template <typename T> struct allocator {
+ 
+   T* allocate(size_t n) {
+     FMT_ASSERT(n <= max_value<size_t>() / sizeof(T), "");
+-    T* p = static_cast<T*>(malloc(n * sizeof(T)));
++    T* p = static_cast<T*>(std::malloc(n * sizeof(T)));
+     if (!p) FMT_THROW(std::bad_alloc());
+     return p;
+   }
+ 
+-  void deallocate(T* p, size_t) { free(p); }
++  void deallocate(T* p, size_t) { std::free(p); }
+ };
+ 
+ }  // namespace detail
diff --git a/meta/recipes-devtools/fmt/fmt_11.2.0.bb b/meta/recipes-devtools/fmt/fmt_11.2.0.bb
index d0d4cea23e2..fd5dc0c4ab7 100644
--- a/meta/recipes-devtools/fmt/fmt_11.2.0.bb
+++ b/meta/recipes-devtools/fmt/fmt_11.2.0.bb
@@ -5,7 +5,9 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=b9257785fc4f3803a4b71b76c1412729"
 
 SRC_URI = "git://github.com/fmtlib/fmt;branch=master;protocol=https;tag=${PV}\
-           file://0001-Workaround-an-ABI-issue-in-spdlog.patch"
+           file://0001-Workaround-an-ABI-issue-in-spdlog.patch \
+           file://0001-Fix-compilation-on-clang-21-libc-21-4477.patch \
+           "
 SRCREV = "40626af88bd7df9a5fb80be7b25ac85b122d6c21"
 
 inherit cmake

Re: [OE-core] [PATCH 1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS

[Mathieu Dubois-Briand]

On Fri Aug 1, 2025 at 6:22 AM CEST, Khem Raj via lists.openembedded.org wrote:
> BUILD_LDFLAGS is used by other recipes to emit native LDFLAGS
> into their cmake toolchain files especially in QT layers. it
> will usually be inherited by recipes wanting clang provide
> BUILD_* variables so this is more appropriate than LDFLAGS to
> pass these options.
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---

Hi Khem,

It looks like something in there is breaking the reproducibility:

AssertionError: The following deb packages are different and not in exclusion list:
/srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/deb/./core2-64/clang-dev_20.1.8-r0_amd64.deb
The following ipk packages are different and not in exclusion list:
/srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/ipk/./core2-64/clang-dev_20.1.8-r0_core2-64.ipk
The following rpm packages are different and not in exclusion list:
/srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/rpm/./core2_64/clang-dev-20.1.8-r0.core2_64.rpm


https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/2205
https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20250801-t697t4fj/packages/diff-html/

Can you have a look at this?

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH 1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS

[Mathieu Dubois-Briand]

On Fri Aug 1, 2025 at 2:54 PM CEST, Mathieu Dubois-Briand wrote:
> On Fri Aug 1, 2025 at 6:22 AM CEST, Khem Raj via lists.openembedded.org wrote:
>> BUILD_LDFLAGS is used by other recipes to emit native LDFLAGS
>> into their cmake toolchain files especially in QT layers. it
>> will usually be inherited by recipes wanting clang provide
>> BUILD_* variables so this is more appropriate than LDFLAGS to
>> pass these options.
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>
> Hi Khem,
>
> It looks like something in there is breaking the reproducibility:
>
> AssertionError: The following deb packages are different and not in exclusion list:
> /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/deb/./core2-64/clang-dev_20.1.8-r0_amd64.deb
> The following ipk packages are different and not in exclusion list:
> /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/ipk/./core2-64/clang-dev_20.1.8-r0_core2-64.ipk
> The following rpm packages are different and not in exclusion list:
> /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/rpm/./core2_64/clang-dev-20.1.8-r0.core2_64.rpm
>
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/2205
> https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20250801-t697t4fj/packages/diff-html/
>
> Can you have a look at this?

I did a rebuild of this one and is succeed. So either we have an
intermittent fail or some cache issue, not really sure...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/2210


-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH 1/7] toolchain/clang-native: Set BUILD_LDFLAGS instead of LDFLAGS

[Khem Raj]

On Fri, Aug 1, 2025 at 9:13 AM Mathieu Dubois-Briand
<mathieu.dubois-briand@bootlin.com> wrote:
>
> On Fri Aug 1, 2025 at 2:54 PM CEST, Mathieu Dubois-Briand wrote:
> > On Fri Aug 1, 2025 at 6:22 AM CEST, Khem Raj via lists.openembedded.org wrote:
> >> BUILD_LDFLAGS is used by other recipes to emit native LDFLAGS
> >> into their cmake toolchain files especially in QT layers. it
> >> will usually be inherited by recipes wanting clang provide
> >> BUILD_* variables so this is more appropriate than LDFLAGS to
> >> pass these options.
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >
> > Hi Khem,
> >
> > It looks like something in there is breaking the reproducibility:
> >
> > AssertionError: The following deb packages are different and not in exclusion list:
> > /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/deb/./core2-64/clang-dev_20.1.8-r0_amd64.deb
> > The following ipk packages are different and not in exclusion list:
> > /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/ipk/./core2-64/clang-dev_20.1.8-r0_core2-64.ipk
> > The following rpm packages are different and not in exclusion list:
> > /srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/rpm/./core2_64/clang-dev-20.1.8-r0.core2_64.rpm
> >
> >
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/2205
> > https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20250801-t697t4fj/packages/diff-html/
> >
> > Can you have a look at this?
>
> I did a rebuild of this one and is succeed. So either we have an
> intermittent fail or some cache issue, not really sure...
>

Possible, I was wondering how build linker flags would insert into
target builds, it's quite unlikely
but still a case. I have dumped the binaries ( strings ) and tried to
catch absolute build path and
did not catch it so far.

> https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/2210
>
>
> --
> Mathieu Dubois-Briand, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>