You must log in or register to comment.
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.
I’m not familiar with the specific install/upgrade process on Gentoo so maybe I’m missing something, but what’s wrong with forcing new installations to use
time64and then forcing existing installs to do some of offline migration from a live disk a decade or so down the line? I feel like it’s probably somewhat uncommon for an installation of any distro to be used continuously for that amount of time (at least in a desktop context), and if anyone could be expected to be able to handle a manual intervention like this, it’s long-time Gentoo users.The bonus of this would be that it wouldn’t be necessary to introduce a new
lib*folder - the entire system either usestime64or it doesn’t. Maybe this still wouldn’t be possible though depending on how source packages are distributed; like I said I dont really know Gentoo.
