|
From: | Paul Eggert |
Subject: | Re: How can Autoconf help with the transition to stricter compilation defaults? |
Date: | Fri, 11 Nov 2022 01:02:20 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 2022-11-10 19:33, Zack Weinberg wrote:
It would be relatively easy for me to take a couple hours this weekend and put out a 2.72 release with everything that's already in trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
I don't have anything other than some doc updates, which I just now installed (see attached).
Note that in autoconf git, we've also got https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60 which is going to affect time_t efforts tooI have not been following the y2038 work closely. Is it going to affect things in a good way or a bad way??
Both.This matters only on 32-bit glibc platforms running atop Linux (and maybe Hurd; I haven't checked). On these platforms, time_t defaults to 32 bits which means programs stop working in the year 2038. But you can change time_t to be 64-bits if you compile with -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64. On other platforms, you don't need to worry about this stuff.
The good news is that if an app uses AC_SYS_LARGEFILE (which most sane apps do), or uses the new macro AC_YEAR2038, it will keep working after the year 2038 on these platforms.
The bad news is that if a library uses AC_SYS_LARGEFILE and/or AC_YEAR2038, and the library code is built without using configure's --disable-largefile option and is linked with a program that doesn't use AC_SYS_LARGEFILE or AC_YEAR2038 or equivalent, and if the library's ABI depends on time_t width, the program might not work.
This is the same issue that AC_SYS_LARGEFILE has had with 32-bit off_t for years (as well as for a few more obscure times like ino_t); what's new is that the problem now occurs with time_t too.
0001-Modernize-and-regularize-doc-for-C89-etc.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |