GNU bug report logs -
#65423
README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3
Previous Next
Full log
Message #11 received at 65423 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-21 21:25, Paul Eggert wrote:
> On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug
> Reports wrote:
>> in 9.3 year 2038 support with 64 bit time_t was made required [1],
>> here on HP-UX this is a bit problematic, but that's not the actual
>> problem. The diff between 9.2 and 9.3 [2] says how this can be fixed
>> on platforms supporting both 32 and 64 bit, on HP-UX it'd be simply
>> '+DD64', and how to avoid with "ac_year2038_required=no", but README-
>> install on master [3] still contains '--disable-year2038' which
>> obviously does not work. It simply needs to be updated to the content
>> of [2].
>
> Sorry, I don't understand. Why does --disable-year2038 not work on HP-UX
> for bleeding-edge coreutils on Savannah?
>
> It sounds like you're suggesting that we revert the attached patch, but
> I don't see how that would be correct as bleeding-edge coreutils/
> configure no longer looks at ac_year2038_required.
No need to be sorry ;-), I understand where your confusion comes from
and mine. I was talking about changes between 9.2 and 9.3 only. Looking
at the changes you refer are solely on master at [1] and [2] which make
year 2038 support optional again. So no action is required anymore.
>> I cannot compile everything in 64 bit mode since no one has written
>> our old applications with portability in mind. It needs to remain 32
>> bit for now.
>
> I suggest compiling coreutils in 64-bit mode now. You can keep compiling
> your other applications in 32-bit mode. Even though HP-UX's end of life
> is the end of 2025, it's possible you'll run across a stray HP-UX file
> today with timestamp after 2038, and basic coreutils apps like 'ls'
> should work with such files.
I agree, and those are just executables. Regardless of this, HPE says at
least until end of 2025, it is at the end a business decision and I am
doing IT, so not my responsibility ;-). I just make it run. The files we
touch go even back to late 80s.
Please go ahead and close this issue, it will auto-resolve with 9.4.
Michael
[1]
https://github.com/coreutils/coreutils/commit/ba128e628cfa0dd111cf235d965200d1cdf77f52
[2]
https://github.com/coreutils/coreutils/commit/3f942cd03fce1a6cda87018306b50f803f08f350#diff-df1edefd8cc0b27219a375d046251a2e9e87fcef6c23767640f12d0b4f784c76L321
This bug report was last modified 1 year and 269 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.