[RFC,v1] package/coreutils: needs toolchain headers >= 5.6 (32-bit system with 64-bit time_t)

Add coreutils dependency on toolchain headers >= 5.6 for 32-bit system to
gain access to 64-bit time_t.

Fixes:

  http://autobuild.buildroot.net/results/a5bac0aaadea43fcedf3a51b070e605e3906c237

  checking for .../host/bin/arm-none-linux-gnueabi-gcc -std=gnu11 option to enable timestamps after Jan 2038... support not detected
  configure: error: in '.../build/coreutils-9.3':
  configure: error: support for timestamps after Jan 2038 is required

Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
Notes:
  - Config.in comment section for package/glslsandbox-player and
    package/opkg-utils missing
  - Not sure if this is sufficient (e.g. possible libc system and/or
    version dependency), other possible solution would be something
    like introducing BR2_TOOLCHAIN_HAS_64_BIT_TIME_T
---
 package/coreutils/Config.in          | 6 ++++--
 package/glslsandbox-player/Config.in | 1 +
 package/opkg-utils/Config.in         | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

On 10/05/2023 22:24, Peter Seiderer wrote:
> Add coreutils dependency on toolchain headers >= 5.6 for 32-bit system to
> gain access to 64-bit time_t.
> 
> Fixes:
> 
>    http://autobuild.buildroot.net/results/a5bac0aaadea43fcedf3a51b070e605e3906c237
> 
>    checking for .../host/bin/arm-none-linux-gnueabi-gcc -std=gnu11 option to enable timestamps after Jan 2038... support not detected
>    configure: error: in '.../build/coreutils-9.3':
>    configure: error: support for timestamps after Jan 2038 is required
> 
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> ---
> Notes:
>    - Config.in comment section for package/glslsandbox-player and
>      package/opkg-utils missing
>    - Not sure if this is sufficient (e.g. possible libc system and/or
>      version dependency), other possible solution would be something
>      like introducing BR2_TOOLCHAIN_HAS_64_BIT_TIME_T

  The current situation of 64-bit time_t is:

	depends on BR2_ARCH_IS_64 || \
		BR2_TOOLCHAIN_USES_MUSL || \
		(BR2_TOOLCHAIN_USES_GLIBC && BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_6)
i.e.:
  - 64-bit platforms always have 64-bit time.
  - musl AFAIK always has 64-bit time in the headers (not sure what happens in 
the actual syscalls).
  - uClibc never has 64-bit time.
  - glibc has 64-bit time with sufficiently recent headers.

  It's actually a bit more complicated still, because on some architectures 
(riscv for example), there's always 64-bit time even if it's a 32-bit 
architecture. So on those, even uClibc has 64-bit time.

  Because of all this complexity, I think it's better to introduce something 
like BR2_TOOLCHAIN_HAS_TIME_T_64 that encodes those conditions. It would be a 
blind symbol that defaults y for 64-bit architectures and is selected by the 
respective arch or toolchain symbols. It's a bit complicated that way, but gives 
us most flexibility to get all the conditions right. For instance, in external 
toolchains it would only be selected if glibc is sufficiently recent.

  Therefore, I've marked this patch as Changes Requested. But I also added the 
other matinainters in Cc because they may have different opinions.

  Regards,
  Arnout

> ---
>   package/coreutils/Config.in          | 6 ++++--
>   package/glslsandbox-player/Config.in | 1 +
>   package/opkg-utils/Config.in         | 2 ++
>   3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/package/coreutils/Config.in b/package/coreutils/Config.in
> index 705013bae0..968c7a97cd 100644
> --- a/package/coreutils/Config.in
> +++ b/package/coreutils/Config.in
> @@ -1,5 +1,6 @@
>   config BR2_PACKAGE_COREUTILS
>   	bool "coreutils"
> +	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_6 || BR2_ARCH_IS_64
>   	depends on BR2_USE_WCHAR
>   	depends on BR2_USE_MMU # fork()
>   	depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
> @@ -33,7 +34,8 @@ comment "coreutils individual binaries need a toolchain w/ dynamic library"
>   
>   endif
>   
> -comment "coreutils needs a toolchain w/ wchar"
> +comment "coreutils needs a toolchain w/ headers >= 5.6 (32-bit only), wchar"
>   	depends on BR2_USE_MMU
> -	depends on !BR2_USE_WCHAR
> +	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_6 && !BR2_ARCH_IS_64 || \
> +		!BR2_USE_WCHAR
>   	depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
> diff --git a/package/glslsandbox-player/Config.in b/package/glslsandbox-player/Config.in
> index 530c158fc3..78d6dd9a6f 100644
> --- a/package/glslsandbox-player/Config.in
> +++ b/package/glslsandbox-player/Config.in
> @@ -32,6 +32,7 @@ config BR2_PACKAGE_GLSLSANDBOX_PLAYER_SCRIPTS
>   	bool "Install scripts"
>   	depends on !BR2_STATIC_LIBS # python3
>   	depends on BR2_TOOLCHAIN_HAS_THREADS # python3
> +	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_6 || BR2_ARCH_IS_64 # coreutls
>   	depends on BR2_USE_MMU # bash, python3
>   	depends on BR2_USE_WCHAR # python3
>   	select BR2_PACKAGE_BASH # runtime
> diff --git a/package/opkg-utils/Config.in b/package/opkg-utils/Config.in
> index 2973055baf..cdefa193b7 100644
> --- a/package/opkg-utils/Config.in
> +++ b/package/opkg-utils/Config.in
> @@ -3,6 +3,8 @@ config BR2_PACKAGE_OPKG_UTILS
>   	depends on !BR2_nios2 || BR2_PACKAGE_BUSYBOX # binutils
>   	depends on BR2_USE_MMU # bash, python3
>   	depends on BR2_USE_WCHAR # python3
> +	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_6 || BR2_ARCH_IS_64 || \
> +		BR2_PACKAGE_BUSYBOX # coreutils
>   	depends on BR2_TOOLCHAIN_HAS_THREADS # python3 <- libffi
>   	depends on !BR2_STATIC_LIBS # python3
>   	select BR2_PACKAGE_BINUTILS if !BR2_PACKAGE_BUSYBOX # runtime

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >  Because of all this complexity, I think it's better to introduce
 >  something like BR2_TOOLCHAIN_HAS_TIME_T_64 that encodes those
 > conditions. It would be a blind symbol that defaults y for 64-bit
 > architectures and is selected by the respective arch or toolchain
 > symbols. It's a bit complicated that way, but gives us most
 > flexibility to get all the conditions right. For instance, in external
 > toolchains it would only be selected if glibc is sufficiently recent.

 >  Therefore, I've marked this patch as Changes Requested. But I also
 >  added the other matinainters in Cc because they may have different
 > opinions.

No, I agree - Nice summary!