| Message ID | 20240406154308.3336009-1-chinhuat@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | package/uclibc: bump to version 1.0.47, add Y2038 config option | expand |
Hello Chin, On Sat, 6 Apr 2024 23:43:08 +0800 Chin Huat Ang <chinhuat@gmail.com> wrote: > +config BR2_UCLIBC_USE_TIME64 > + bool "Use 64-bit date and time functions (Y2038-ready)" > + depends on !BR2_ARCH_IS_64 > + default n > + help > + Enabling this option for 32-bit targets will configure > + uClibc with config UCLIBC_USE_TIME64=y which enables 64-bit > + date and time handling to support date/time beyond Y2038. Thanks a lot for your patch! I don't think we should add a BR2_UCLIBC_USE_TIME64 option. Instead, there is already a BR2_TIME_BITS_64, which enables 64-bit time_t for glibc. It simply needs to be extended to also allow enabling 64-bit time_t in uClibc. Also, can I suggest that you split your change into two commits? One bumping uClibc to 1.0.47, and one making it possible to configure it with 64-bit time_t? Thanks a lot! Thomas
Hi Thomas, > I don't think we should add a BR2_UCLIBC_USE_TIME64 option. Instead, > there is already a BR2_TIME_BITS_64, which enables 64-bit time_t for > glibc. It simply needs to be extended to also allow enabling 64-bit > time_t in uClibc. I contemplated reusing BR2_TIME_BITS_64 but I noticed it has a widespread impact of causing many packages to be configured with -D_TIME_BITS=64 due to these in package/Makefile.in: ifeq ($(BR2_TIME_BITS_64),y) TARGET_CPPFLAGS += -D_TIME_BITS=64 endif TARGET_CFLAGS = $(TARGET_CPPFLAGS) $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) $(TARGET_HARDENED) TARGET_CXXFLAGS = $(TARGET_CFLAGS) ... TARGET_CONFIGURE_OPTS = \ ... CPPFLAGS="$(TARGET_CPPFLAGS)" \ CFLAGS="$(TARGET_CFLAGS)" \ CXXFLAGS="$(TARGET_CXXFLAGS)" \ ... I wasn't sure if this is the right thing to do but at the very least whenever uClib is used, my intention was to only configure itself with UCLIBC_USE_TIME64. Assuming if BR2_TIME_BITS_64 applies to both glibc and uClibc, should -D_TIME_BITS=64 only be appended to glibc GLIBC_EXTRA_CFLAGS? > Also, can I suggest that you split your change into two commits? One > bumping uClibc to 1.0.47, and one making it possible to configure it > with 64-bit time_t? That's a good idea, I guess I was too focused on trying out uClib's Y2038 solution. I'll split the patch up as you suggested. --Chin Huat
On 07/04/2024 19:47, Chin Huat Ang wrote: > Hi Thomas, > >> I don't think we should add a BR2_UCLIBC_USE_TIME64 option. Instead, >> there is already a BR2_TIME_BITS_64, which enables 64-bit time_t for >> glibc. It simply needs to be extended to also allow enabling 64-bit >> time_t in uClibc. > > I contemplated reusing BR2_TIME_BITS_64 but I noticed it has a > widespread impact of causing many packages to be configured with > -D_TIME_BITS=64 due to these in package/Makefile.in: > > ifeq ($(BR2_TIME_BITS_64),y) > TARGET_CPPFLAGS += -D_TIME_BITS=64 > endif > TARGET_CFLAGS = $(TARGET_CPPFLAGS) $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) $(TARGET_HARDENED) > TARGET_CXXFLAGS = $(TARGET_CFLAGS) > ... > TARGET_CONFIGURE_OPTS = \ > ... > CPPFLAGS="$(TARGET_CPPFLAGS)" \ > CFLAGS="$(TARGET_CFLAGS)" \ > CXXFLAGS="$(TARGET_CXXFLAGS)" \ > ... > > I wasn't sure if this is the right thing to do but at the very least > whenever uClib is used, my intention was to only configure itself with > UCLIBC_USE_TIME64. > > Assuming if BR2_TIME_BITS_64 applies to both glibc and uClibc, should > -D_TIME_BITS=64 only be appended to glibc GLIBC_EXTRA_CFLAGS? IMHO the question is if uClibc acts like musl (i.e. unconditionally enable 64-bit time, which breaks binaries that were compiled with 32-bit time) or like glibc (i.e. the compiled library supports both 32-bit and 64-bit time, and applications use the one or other version depending on _TIME_BITS). I _think_ that uClibc acts like musl. In that case, passing -D_TIME_BITS=64 doesn't make any sense. And therefore, having the option at uClibc level makes more sense. However, I don't think it's very useful to have this configuration knob in Buildroot's config. What I would do instead is to unconditionally change our bundled uClibc config to enable 64-bit time, and let people provide their own config if for some reason they don't want 64-bit time. Note that we currently don't have anything like BR2_TOOLCHAIN_HAS_TIME_BITS_64, i.e. a symbol that says if libc supports 64-bit time or not. I don't actually think it's useful - I guess that if packages need to know this, they'll have a configure script to test for it. But _if_ we would have such an option, _then_ a Buildroot config option for uClibc would make sense (because you have to be able to know at Buildroot config level if uClibc config has it enabled or not). Regards, Arnout > >> Also, can I suggest that you split your change into two commits? One >> bumping uClibc to 1.0.47, and one making it possible to configure it >> with 64-bit time_t? > > That's a good idea, I guess I was too focused on trying out uClib's > Y2038 solution. I'll split the patch up as you suggested. > > --Chin Huat > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
On Sun, 7 Apr 2024 21:30:09 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > IMHO the question is if uClibc acts like musl (i.e. unconditionally enable > 64-bit time, which breaks binaries that were compiled with 32-bit time) or like > glibc (i.e. the compiled library supports both 32-bit and 64-bit time, and > applications use the one or other version depending on _TIME_BITS). > > I _think_ that uClibc acts like musl. In that case, passing -D_TIME_BITS=64 > doesn't make any sense. And therefore, having the option at uClibc level makes > more sense. However, I don't think it's very useful to have this configuration > knob in Buildroot's config. What I would do instead is to unconditionally change > our bundled uClibc config to enable 64-bit time, and let people provide their > own config if for some reason they don't want 64-bit time. If we go this way, then we should also do it for glibc, and drop BR2_TIME_BITS_64. Thomas
On 07/04/2024 23:11, Thomas Petazzoni wrote: > On Sun, 7 Apr 2024 21:30:09 +0200 > Arnout Vandecappelle <arnout@mind.be> wrote: > >> IMHO the question is if uClibc acts like musl (i.e. unconditionally enable >> 64-bit time, which breaks binaries that were compiled with 32-bit time) or like >> glibc (i.e. the compiled library supports both 32-bit and 64-bit time, and >> applications use the one or other version depending on _TIME_BITS). >> >> I _think_ that uClibc acts like musl. In that case, passing -D_TIME_BITS=64 >> doesn't make any sense. And therefore, having the option at uClibc level makes >> more sense. However, I don't think it's very useful to have this configuration >> knob in Buildroot's config. What I would do instead is to unconditionally change >> our bundled uClibc config to enable 64-bit time, and let people provide their >> own config if for some reason they don't want 64-bit time. > > If we go this way, then we should also do it for glibc, and drop > BR2_TIME_BITS_64. glibc is different though: it always supports both 32-bit and 64-bit time, and you have to supply the -D_TIME_BITS=64 explicitly. You can't force glibc to always have 64-bit time, individual packages will always be able to override it. On the other hand, in uClibc, it _is_ still possible for a user to configure the library with 32-bit time (only). We just default to 64-bit time. We could unconditionally enable -D_TIME_BITS=64, similar to how we do it for largefile. But that's pretty much independent of what we do with uClibc. Regards, Arnout
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in index 2555487f06..475bca14f0 100644 --- a/package/uclibc/Config.in +++ b/package/uclibc/Config.in @@ -120,6 +120,15 @@ config BR2_UCLIBC_INSTALL_UTILS You can save ~32 KiB in target space by disabling them since they're normally not needed. +config BR2_UCLIBC_USE_TIME64 + bool "Use 64-bit date and time functions (Y2038-ready)" + depends on !BR2_ARCH_IS_64 + default n + help + Enabling this option for 32-bit targets will configure + uClibc with config UCLIBC_USE_TIME64=y which enables 64-bit + date and time handling to support date/time beyond Y2038. + # Mapping from the Buildroot architecture configuration options to the # uClibc architecture names. config BR2_UCLIBC_TARGET_ARCH diff --git a/package/uclibc/uclibc.hash b/package/uclibc/uclibc.hash index ae1f3178d9..a10ceab54c 100644 --- a/package/uclibc/uclibc.hash +++ b/package/uclibc/uclibc.hash @@ -1,4 +1,4 @@ -# From https://downloads.uclibc-ng.org/releases/1.0.44/uClibc-ng-1.0.45.tar.xz.sha256 -sha256 c2f4c6b6e19d7c9c226992a3746efd7ab932040463c15ee0bc8f4132b5777ac4 uClibc-ng-1.0.45.tar.xz +# From https://downloads.uclibc-ng.org/releases/1.0.47/uClibc-ng-1.0.47.tar.xz.sha256 +sha256 29a4d684a06da344ee3ee09acc2ca7649d592ae3ff848f698145c46def05efcb uClibc-ng-1.0.47.tar.xz # Locally calculated sha256 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk index 88623840bf..3ca541bcda 100644 --- a/package/uclibc/uclibc.mk +++ b/package/uclibc/uclibc.mk @@ -4,7 +4,7 @@ # ################################################################################ -UCLIBC_VERSION = 1.0.45 +UCLIBC_VERSION = 1.0.47 UCLIBC_SOURCE = uClibc-ng-$(UCLIBC_VERSION).tar.xz UCLIBC_SITE = https://downloads.uclibc-ng.org/releases/$(UCLIBC_VERSION) UCLIBC_LICENSE = LGPL-2.1+ @@ -371,6 +371,17 @@ else UCLIBC_SHARED_LIBS_CONFIG = $(call KCONFIG_ENABLE_OPT,HAVE_SHARED) endif +# +# time64 +# + +ifeq ($(BR2_UCLIBC_USE_TIME64),y) +UCLIBC_TIME64_CONFIG = $(call KCONFIG_ENABLE_OPT,UCLIBC_USE_TIME64) +else +UCLIBC_TIME64_CONFIG = $(call KCONFIG_DISABLE_OPT,UCLIBC_USE_TIME64) +endif + + # # Commands # @@ -423,6 +434,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_LOCALE_CONFIG) $(UCLIBC_WCHAR_CONFIG) $(UCLIBC_SHARED_LIBS_CONFIG) + $(UCLIBC_TIME64_CONFIG) endef define UCLIBC_BUILD_CMDS
uClibc introduced UCLIBC_USE_TIME64 config since v1.0.46 which enables 64-bit date and time handling on 32-bit targets to solve Y2038 issue. As of v1.0.47, most 32-bit buildroot/uClibc targets appear to support 64-bit date/time. Here we add the equivalent BR2_UCLIBC_USE_TIME64 package config which is only meant for 32-bit target architectures. This config is disabled by default as it has only been sanity tested. When disabled, uClibc's Y2038 issue can be easily reproduced/observed on 32-bit targets: # uname -a; date -s @2147483647; date +%s; sleep 1; date; date +%s Linux buildroot 6.1.44 #1 SMP Sat Apr 6 19:05:05 +08 2024 armv7l GNU/Linux Tue Jan 19 03:14:07 UTC 2038 2147483647 Fri Dec 13 20:45:52 UTC 1901 -2147483648 With BR2_UCLIBC_USE_TIME64=y, the Y2038 issue goes away: # uname -a; date -s @2147483647; date +%s; sleep 1; date; date +%s Linux buildroot 6.1.44 #1 SMP Sat Apr 6 17:43:14 +08 2024 armv7l GNU/Linux Tue Jan 19 03:14:07 UTC 2038 2147483647 Tue Jan 19 03:14:08 UTC 2038 2147483648 The following 32-bit target architectures have been sanity tested: - ARMv7-A Cortex-A9 on qemu_arm_vexpress_defconfig - Generic MIPS32R2 on qemu_mips32r2_malta_defconfig - i386/Pentium Pro on qemu_x86_defconfig - Xtensa on qemu_xtensa_lx60_defconfig Git shortlog of other changes (tags/v1.0.45..tags/v1.0.47): Dmitry Chestnykh (23): Fix redefinition of _GNU_SOURCE. ld.so: Add support of DT_RELR relocation format. libc: Fix dns-related build issues. Add extra `-shared` to link.so command. Fix broken compilation of uClibc-ng. Rename `reloc_addr` to suppress `-Wshadow` warning. Introduce time64 support. xtensa: Add time64 support. ldso: Remove unneeded semicolons. Remove unneeded comparisons. Add support for using time64 on big-endian machines. Add time64 support for PowerPC. Refactor `ts32_struct` and `TO_ITS64_P`. Add time64 support for MIPS32. Fix *stat() and *stat64() when the time is beyond year 2038. ldso: Use statx() when time64 is enabled. libc: always redirect *stat() family to statx() with time64 enabled. libc: Pass 64bit-only time structures to syscalls. Add time64 support to OpenRISC. Add time64 support for sparc. libc: restore correct definition of semid_ds struct. libc: Remove 32bit timespec structures everywhere. Add time64 support to ARC. Frank Mehnert (1): ldso: add null-pointer check Marcus Haehnel (4): Remove duplicate semicolons libm/w_j0f.c: Call correct ieee754 function libpthread: Remove no longer valid attribute_unused libpthread/linuxthreads: add missing string.h include in condvar.c Marius Melzer (2): Fix -Wgnu-designator clang warnings Fix -Wnon-literal-null-conversion clang warning Paul Cercueil (3): sys/stat.h: Make S_ISSOCK() available if __USE_XOPEN2K sys/stat.h: Make fchmod() available if __USE_XOPEN2K features.h: Rework _DEFAULT_SOURCE Sven Linker (3): Avoid fall-through if file matching temporary name exists libc: Fix some unused parameter warnings Replace null subtraction with cast Waldemar Brodkorb (25): c6x: fix duplicate include add newline at end of file fix c6x toolchain compile remove symlink riscv32: decouple from riscv64 riscv32: add ldso support, enable time64. riscv32: add basic support for NPTL microblaze: enable time64 superh: enable time64 m68k: enable time64 x86: enable time64 update MAINTAINERS bump version for 1.0.46 release add reallocarray from musl add explicit_bzero from musl riscv64: sync with glibc, fix all TLS errors in uClibc-ng-test riscv64: page size is 4096, reported by sorear riscv64: sync with glibc clone.S riscv64: clone behaves like on aarch64, fixes tst-basic3, reported by sorear riscv64: add atomic.h, fixes tst-cond16, suggested by sorear riscv32: sync with riscv64 riscv64: enable CTORS, fixes C++ applications, found by sorear riscv: fix pread64/pwrite64 users like git, suggested by sorear riscv: add __UCLIBC_ABORT_INSTRUCTION__, suggested by sorear bump version for 1.0.47 release Signed-off-by: Chin Huat Ang <chinhuat@gmail.com> --- package/uclibc/Config.in | 9 +++++++++ package/uclibc/uclibc.hash | 4 ++-- package/uclibc/uclibc.mk | 14 +++++++++++++- 3 files changed, 24 insertions(+), 3 deletions(-)