In the Overview of cross-architecture portability problems, I have dedicated a section to the problems resulting from use of 32-bit time_t type. This design decision, still affecting Gentoo systems…
This seems overblown, we’ve faced these things before.
The straightforward path is adding new calls and structs and leaving the old code in place, then having tests that return -1 for time32_t and seeing what breaks.
It’s not pretty, but this is life in the new epoch, gentoo doesn’t have it harder than anyone else except when they’re trying to rebuild while the transition is happening.
I know nobody wants 2 apis, 1 deprecated, but this is an ancient design decision we have to live with, this is how we live with them.
Ah, the joys of requiring non-standard library calls for apps to function.
The problem is that this approach breaks the C standard library API, which is one of the few things that are actually pretty universal and expected to work on any platform. You don’t want to force app developers to support your snowflake OS that doesn’t support C.
The current way forward accepted by every other distro is to just recompile everything against the new 64-bit libraries. Unless the compiled software makes weird hardcoded assumptions about sizes of structs (hand-coded assembly might be one somewhat legitimate reason for that, but other distros have been migrating to 64-bit time_t for long enough that this should have been caught already), this fixes the problem entirely for software that can be recompiled.
That leaves just the proprietary software, for which you can either have a separate library path with 32-bit time_t dependencies, or use containers to effectively do the same.
Sneaky edit: why not add new 64-bit APIs to C? Because the C standard never said anything about how to represent time_t. If the chosen implementation is insufficient, it’s purely on the platform to fix it. The C17 standard:
The range and precision of times representable in clock_t and time_t are implementation-defined.
This seems overblown, we’ve faced these things before.
The straightforward path is adding new calls and structs and leaving the old code in place, then having tests that return -1 for time32_t and seeing what breaks.
It’s not pretty, but this is life in the new epoch, gentoo doesn’t have it harder than anyone else except when they’re trying to rebuild while the transition is happening.
I know nobody wants 2 apis, 1 deprecated, but this is an ancient design decision we have to live with, this is how we live with them.
Ah, the joys of requiring non-standard library calls for apps to function.
The problem is that this approach breaks the C standard library API, which is one of the few things that are actually pretty universal and expected to work on any platform. You don’t want to force app developers to support your snowflake OS that doesn’t support C.
The current way forward accepted by every other distro is to just recompile everything against the new 64-bit libraries. Unless the compiled software makes weird hardcoded assumptions about sizes of structs (hand-coded assembly might be one somewhat legitimate reason for that, but other distros have been migrating to 64-bit time_t for long enough that this should have been caught already), this fixes the problem entirely for software that can be recompiled.
That leaves just the proprietary software, for which you can either have a separate library path with 32-bit time_t dependencies, or use containers to effectively do the same.
Sneaky edit: why not add new 64-bit APIs to C? Because the C standard never said anything about how to represent time_t. If the chosen implementation is insufficient, it’s purely on the platform to fix it. The C17 standard: