[Buildroot] [PATCH] package/uclibc: bump to version 1.0.47, add Y2038 config option
Chin Huat Ang
chinhuat at gmail.com
Sun Apr 7 17:47:08 UTC 2024
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
More information about the buildroot
mailing list