From: Ola x Nilsson <ola.x.nilsson@axis.com>
To: <openembedded-core@lists.openembedded.org>
Cc: "niko.mauno@vaisala.com" <niko.mauno@vaisala.com>
Subject: Re: [OE-core] [RFC PATCH 1/3] Try to ensure 64 bit time on 32 bit glibcful hosts
Date: Tue, 8 Nov 2022 11:51:58 +0100 [thread overview]
Message-ID: <jwqh6z9soii.fsf@axis.com> (raw)
In-Reply-To: <20221108000828.42824-1-niko.mauno@vaisala.com>
I'm working on the same thing, but I put GLIBC_64BIT_TIME_CPPFLAGS in
TARGET_CC_ARCH instead to make sure they applied everywhere.
I'd be interested to hear what others think is the best place to put
these flags.
I'm also looking at QA tests to make sure that no application or shared
object is still using 32bit time or file functions from glibc.
/Ola
On Tue, Nov 08 2022, Niko Mauno via lists.openembedded.org wrote:
> Add default C Preprocessor flags that ensure Y2038 compatible 64 bit
> time on 32 bit host applications when glibc is used. Prerequisites
> are glibc version 2.34 or newer and Linux kernel version 5.1 or newer.
>
> Example of impact on 32 bit 'qemuarm' machine running
> core-image-minimal. Before this change:
>
> root@qemuarm:~# /bin/busybox date
> Sun Nov 6 06:09:39 UTC 2022
> root@qemuarm:~# /sbin/hwclock.util-linux -w
> root@qemuarm:~# /sbin/hwclock.util-linux
> 2022-11-06 06:09:49.994249+00:00
> root@qemuarm:~# /bin/busybox date -s 2040-01-01
> date: invalid date '2040-01-01'
> root@qemuarm:~# /bin/date.coreutils -s 2040-01-01
> Sun Jan 1 00:00:00 UTC 2040
> root@qemuarm:~# /sbin/hwclock.util-linux -w
> root@qemuarm:~# /sbin/hwclock.util-linux
> 1931-03-04 06:26:23.000000+00:00
> root@qemuarm:~#
>
> After this change:
>
> root@qemuarm:~# /bin/busybox date
> Sun Nov 6 06:02:20 UTC 2022
> root@qemuarm:~# /sbin/hwclock.util-linux -w
> root@qemuarm:~# /sbin/hwclock.util-linux
> 2022-11-06 06:02:27.989730+00:00
> root@qemuarm:~# /bin/busybox date -s 2040-01-01
> Sun Jan 1 00:00:00 UTC 2040
> root@qemuarm:~# /sbin/hwclock.util-linux -w
> root@qemuarm:~# /sbin/hwclock.util-linux
> 2040-01-01 00:00:20.992954+00:00
> root@qemuarm:~#
>
> From here on, the adding of new flags can be disabled on recipe or
> global level by resetting the value of associated variable containing
> the CPPFLAGS specific for 64 bit time
>
> GLIBC_64BIT_TIME_CPPFLAGS = ""
>
> which can be useful e.g. when working around failure to compile a
> component due to lack of 64 bit time support on 32 bit build in the
> component's source code.
>
> Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
> ---
> meta/conf/distro/include/tclibc-glibc.inc | 3 +++
> meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb | 2 ++
> meta/recipes-devtools/pseudo/pseudo_git.bb | 2 ++
> 3 files changed, 7 insertions(+)
>
> diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
> index f48d16939e..95770298e9 100644
> --- a/meta/conf/distro/include/tclibc-glibc.inc
> +++ b/meta/conf/distro/include/tclibc-glibc.inc
> @@ -17,6 +17,9 @@ PREFERRED_PROVIDER_virtual/crypt ?= "libxcrypt"
>
> CXXFLAGS += "-fvisibility-inlines-hidden"
>
> +GLIBC_64BIT_TIME_CPPFLAGS = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
> +TARGET_CPPFLAGS += "${GLIBC_64BIT_TIME_CPPFLAGS}"
> +
> LIBC_DEPENDENCIES = "\
> glibc \
> glibc-dbg \
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> index 8bda2ccad6..b3fafa0ea4 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> @@ -5,3 +5,5 @@ require gcc-sanitizers.inc
> # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
> ARM_INSTRUCTION_SET:armv4 = "arm"
> ARM_INSTRUCTION_SET:armv5 = "arm"
> +
> +GLIBC_64BIT_TIME_CPPFLAGS = ""
> diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb
> index c34580b4ff..7734d0fbb0 100644
> --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> @@ -19,3 +19,5 @@ PV = "1.9.0+git${SRCPV}"
>
> # error: use of undeclared identifier '_STAT_VER'
> COMPATIBLE_HOST:libc-musl = 'null'
> +
> +GLIBC_64BIT_TIME_CPPFLAGS = ""
next prev parent reply other threads:[~2022-11-08 10:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 0:08 [RFC PATCH 1/3] Try to ensure 64 bit time on 32 bit glibcful hosts Niko Mauno
2022-11-08 0:08 ` [RFC PATCH 2/3] kbd: Disable 64 bit time with 32 bit glibc Niko Mauno
2022-11-08 9:14 ` [OE-core] " Alexander Kanavin
2022-11-08 11:48 ` Niko Mauno
2022-11-08 11:50 ` Alexander Kanavin
2022-11-08 12:04 ` Niko Mauno
2022-11-08 12:18 ` Alexander Kanavin
[not found] ` <17259B3874804FB3.24550@lists.openembedded.org>
2022-11-08 12:57 ` Alexander Kanavin
2022-11-08 14:56 ` Ola x Nilsson
2022-11-08 15:00 ` Ola x Nilsson
[not found] ` <1725A47F2FC9966F.2170@lists.openembedded.org>
2022-11-08 17:56 ` Ola x Nilsson
2022-11-08 18:38 ` Alexander Kanavin
2022-11-09 7:44 ` Ola x Nilsson
2022-11-09 15:42 ` Alexandre Belloni
2022-11-08 16:40 ` Khem Raj
2022-11-08 16:45 ` Alexander Kanavin
2022-11-08 0:08 ` [RFC PATCH 3/3] pulseaudio: " Niko Mauno
2022-11-08 10:17 ` [OE-core] " Peter Kjellerstedt
2022-11-08 3:30 ` [OE-core] [RFC PATCH 1/3] Try to ensure 64 bit time on 32 bit glibcful hosts Khem Raj
2022-11-08 10:51 ` Ola x Nilsson [this message]
2022-11-08 16:38 ` Khem Raj
2022-11-09 6:33 ` Niko Mauno
2022-11-09 15:47 ` Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwqh6z9soii.fsf@axis.com \
--to=ola.x.nilsson@axis.com \
--cc=niko.mauno@vaisala.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox