[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