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

Arnout Vandecappelle arnout at mind.be
Tue Apr 9 12:23:47 UTC 2024



On 07/04/2024 23:11, Thomas Petazzoni wrote:
> On Sun, 7 Apr 2024 21:30:09 +0200
> Arnout Vandecappelle <arnout at 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



More information about the buildroot mailing list