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

Arnout Vandecappelle arnout at mind.be
Sun Apr 7 19:30:09 UTC 2024



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 at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot



More information about the buildroot mailing list