You also need to adjust the kernel API required by the glibc to be 5.14 as well.

OLDEST_KERNEL = "5.14"

Without doing that, the system will used the default version which does NOT include support for time64 based syscalls. (5.1 is the minimum version required to enable the time64 support.)

defaults are in meta/conf/bitbake.conf.  For honister:

OLDEST_KERNEL = "3.2.0"
OLDEST_KERNEL:aarch64 = "3.14"
OLDEST_KERNEL:nios2 = "3.19"
OLDEST_KERNEL:powerpc64le = "3.10.0"
OLDEST_KERNEL:riscv32 = "5.4"
OLDEST_KERNEL:riscv64 = "4.15"

The reason that OLDEST_KERNEL defaults to (generally) 3.X, is that when QEMU application support is used to help cross-compile an application, if your host system doesn't have a new enough kernel running target glibc can fail in this emulated environment.

The defaults are defined to work with the supported hosts, include RHEL 7 which is monumentally out of date [from a kernel version] perspective.

So long story short. Update your build host to a modern version of an OS with a 5.x kernel. Then update your OLDEST_KERNEL setting to at LEAST 5.1.

and THEN following the advice mentioned in this thread about configuring, recompiling and having to check individual applications for 32/64 time_t support.

--Mark

On 2/22/22 6:19 PM, Martin Leduc wrote:
Hi Khem,

Thank you to your comment.  Not sure to get you.  My comprehension is that the 
Y2038 bug is controlled by the Kernel 5.14 and Glibc 2.34, aligned with Yocto 
Honister for 32bits architecture, arm or x86.

I understand the point that a 32 bits Architecture need code adaptation to 
handles 64 bits variables, but I don’t understand your point, if the fix is 
managed by the two flags, with respect the time_t var.

Could you please more precise?

Martin Leduc
T : (418) 856-6896
[email protected]


-----Message d'origine-----
De : Khem Raj <[email protected]>
Envoyé : 22 février 2022 17:49
À : Martin Leduc <[email protected]>
Cc : Richard Purdie <[email protected]>; Ross Burton 
<[email protected]>; Phil Blundell <[email protected]>; 
[email protected]
Objet : [EXTERNAL] Re: [Openembedded-architecture] ARM32 Millenium Bug

CAUTION: This email originated from outside of Luminator Technology Group. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Tue, Feb 22, 2022 at 1:41 PM Martin Leduc <[email protected]> wrote:

LOLLL, Yes, I'Ve figure this AFTER having sent the email...



Sorry, I'm not a Yocto Guru 😉



I currently try this with core-image-minimal

TARGET_CFLAGS:append = " -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 "

TARGET_CXXFLAGS:append = " -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 "



We will see.


the apps has to be able to use 64bit time_t as well, so it won't be just these 
flags but perhaps more that you will need



Thanks



Martin Leduc

T : (418) 856-6896

[email protected]





-----Message d'origine-----
De : Richard Purdie <[email protected]>
Envoyé : 22 février 2022 16:28
À : Martin Leduc <[email protected]>; Ross Burton
<[email protected]> Cc : Phil Blundell <[email protected]>;
[email protected]
Objet : [EXTERNAL] Re: [Openembedded-architecture] ARM32 Millenium Bug



CAUTION: This email originated from outside of Luminator Technology Group. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.



On Tue, 2022-02-22 at 18:30 +0000, Martin Leduc wrote:

Hi Ross, after doing a grep to fine the defines, I've found that the defines 
refer to __USE_TIME_BITS64, instead of _TIME_BITS=64.



The two defined flags appear to do not work "CFLAGS:append = " -D_TIME_BITS=64  
-D_USE_TIME_BITS64"



At this time only CFLAGS:append = " -D_USE_TIME_BITS64 " compile successfully.



I think you want TARGET_CFLAGS:append



Cheers,



Richard










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1494): 
https://lists.openembedded.org/g/openembedded-architecture/message/1494
Mute This Topic: https://lists.openembedded.org/mt/89315888/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to