3c427c6472
Y2038 is now almost only 15 years away, and embedded systems built today are potentially going to still be operational in 15 years, and even though they are supposed to receive updates by then, we all know how things go, and potentially some of these embedded systems will not receive any update. In 2038, the signed 32-bit representation of time_t used on 32-bit architectures will overflow, causing all time-related functions to go back in time in a surprising way. The Linux kernel has already been modified to support a 64-bit representation of time_t on 32-bit architectures, but from a C library perspective, the situation varies: - glibc uses this 64-bit time_t representation on 32-bit systems since glibc 2.34, but only if -D_TIME_BITS=64 is specified. Therefore, this commit adds an option to add this flag globally to the build, when glibc is the C library and the architecture is not 64-bit. - musl uses unconditionally a 64-bit time_t representation on 32-bit systems since musl 1.2.0. So there is nothing to do here since Buildroot has been using a musl >= 1.2.0, used since Buildroot 2020.05. No Buildroot option is needed here. - uClibc-ng does not support a 64-bit time_t representation on 32-bit systems, so systems using uClibc-ng will not be Y2038 compliant, at least for now. No Buildroot option is needed here. It should be noted that being Y2038-compliant will only work if all application/library code is correct. For example if an application/library stores a timestamp in an "int" instead of using the proper time_t type, then the mechanisms described above will not fix this, and the application/library will continue to be broken in terms of Y2038 support. Possible discussions points about this patch: - Should we have an option at all, or should we unconditionally pass -D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64 for quite some time. The reasoning for having an option is that the mechanism is itself opt-in in glibc, and generally relatively new, so it seemed logical for now to make it optional as well in Buildroot. - Should we show something (a Config.in comment?) in the musl and uClibc-ng case to let the user know that the code is Y2038 compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this discussion be part of the Buildroot documentation? Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> |
||
|---|---|---|
| arch | ||
| board | ||
| boot | ||
| configs | ||
| docs | ||
| fs | ||
| linux | ||
| package | ||
| support | ||
| system | ||
| toolchain | ||
| utils | ||
| .checkpackageignore | ||
| .clang-format | ||
| .defconfig | ||
| .flake8 | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .shellcheckrc | ||
| CHANGES | ||
| Config.in | ||
| Config.in.legacy | ||
| COPYING | ||
| DEVELOPERS | ||
| Makefile | ||
| Makefile.legacy | ||
| README | ||
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches