[Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Chin Huat Ang]

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(-)

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
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Thomas Petazzoni via buildroot]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Chin Huat Ang]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Arnout Vandecappelle via buildroot]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Thomas Petazzoni via 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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option

[Arnout Vandecappelle via buildroot]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot