diff mbox series

[v2] time64: enable 64-bit time/file-offset flags for 32-bit nativesdk

Message ID 20260529170117.2241639-1-peter.tatrai.ext@siemens.com
State New
Headers show
Series [v2] time64: enable 64-bit time/file-offset flags for 32-bit nativesdk | expand

Commit Message

Tatrai, Peter May 29, 2026, 5:01 p.m. UTC
From: Peter Tatrai <peter.tatrai.ext@siemens.com>

When SDKMACHINE is set to i686 or i586, nativesdk binaries are compiled
as 32-bit. Without -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64, stat()
and time-related syscalls use 32-bit types, causing EOVERFLOW on
filesystems with large inode numbers (e.g. container overlay filesystems)
and Y2038 issues.

Add SDK_CC_ARCH appends for class-nativesdk:i686 and class-nativesdk:i586
using GLIBC_64BIT_TIME_FLAGS, mirroring how target architectures are
handled.

Signed-off-by: Peter Tatrai <peter.tatrai.ext@siemens.com>"
---
v2: Set both _TIME_BITS=64 and _FILE_OFFSET_BITS=64 globally in
    time64.inc for all nativesdk packages on i686/i586, as suggested
    by Richard Purdie. Drop the ninja-specific fix.

 meta/conf/distro/include/time64.inc | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Alexander Kanavin May 29, 2026, 5:16 p.m. UTC | #1
On Fri, 29 May 2026 at 19:01, Tatrai, Peter via lists.openembedded.org
<peter.tatrai.ext=siemens.com@lists.openembedded.org> wrote:
> When SDKMACHINE is set to i686 or i586, nativesdk binaries are compiled
> as 32-bit. Without -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64, stat()
> and time-related syscalls use 32-bit types, causing EOVERFLOW on
> filesystems with large inode numbers (e.g. container overlay filesystems)
> and Y2038 issues.

Hurray! As chance would have it, we have just recently discussed
dropping Yocto CI testing for SDKs that run on 32 bit hosts. The
trigger for that discussion was that latest qemu can no longer run on
such hosts (but it can emulate 32 bit platforms just fine, that is not
going away). RP had mentioned that someone has recently submitted a
fix, and presumably they have a use case, and that someone is you.

So the question: how and why are you using such SDKs? Would you be
very upset if Yocto no longer tests them?

Alex
diff mbox series

Patch

diff --git a/meta/conf/distro/include/time64.inc b/meta/conf/distro/include/time64.inc
index 19177b1f3c..a2fe03354d 100644
--- a/meta/conf/distro/include/time64.inc
+++ b/meta/conf/distro/include/time64.inc
@@ -38,6 +38,16 @@  TARGET_CC_ARCH:append:x86 = "${@bb.utils.contains('TUNE_FEATURES', 'm32', '${GLI
 GLIBC_64BIT_TIME_FLAGS:pn-glibc = ""
 GLIBC_64BIT_TIME_FLAGS:pn-glibc-testsuite = ""
 
+# Apply the same flags to nativesdk packages when building for a 32-bit SDK
+# host (i686, i586).
+SDK_CC_ARCH:append:class-nativesdk:i686 = "${GLIBC_64BIT_TIME_FLAGS}"
+SDK_CC_ARCH:append:class-nativesdk:i586 = "${GLIBC_64BIT_TIME_FLAGS}"
+
+# nativesdk-pseudo wraps both 32-bit and 64-bit libc calls; enabling LFS flags
+# causes duplicate symbol errors (e.g. creat64, fopen64) on i686 because glibc
+# aliases the non-LFS names to their 64-bit counterparts via macros.
+GLIBC_64BIT_TIME_FLAGS:pn-nativesdk-pseudo = ""
+
 # Caused by the flags exceptions above
 INSANE_SKIP:append:pn-glibc = " 32bit-time"