mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

342K
active users

The time_t is now.

Debian: 64-bit time_t transition in progress:

The goal of this transition is to ensure that 32-bit architectures in trixie (whether they are currently release architectures, or out of archive, etc) will be capable of handling...
jwz.org/b/ykMI

@jwz the glibc roadmap, to provide entry points for both 32- and 64-bit time_t, is sensible for glibc as the base runtime library package for the C ecosystem.

It is not sensible to apply this for 1200-ish libraries, each of which has a much smaller number of reverse dependencies than glibc.

We're just rebuilding the libraries with TIME_BITS=64, and forcing software requiring the 32-bit time_t off the system with package conflicts.

@vorlon What does that mean for a non-distro-provided binary that was built without =64 that calls a distro-provided library function with an arg whose size has changed? Will that trigger a dylib error like it would with glibc's function renaming? Don't you need each of those libs to do the same renaming trick to avoid smashing memory?

@jwz well, first, note that x86 is not getting 64-bit time_t as part of this. The majority view is that 32-bit x86 ("i386" in Debian architectures) is itself a legacy ABI whose main value is for compatibility with 3rd party binaries. If you can rebuild your application at all, you should rebuild it for 64-bit ISA, not just 64-bit time_t. So we don't touch i386 with this but leave it compatible.

That leaves the "other" 32-bit archs. Currently for Debian itself, that means armhf (and armel).

@jwz if this were Android, then compatibility with 3rd-party ARM binaries would be a significant concern. But the install base of armhf is a fraction of i386, and the ecosystem of 3rd-party binaries for ARM on GNU/Linux is, as far as I'm aware, diminishingly small.

Any ARM binaries out in the wild that ARE dynamically linked against libraries besides glibc, and which are not distributed via Debian packages, do stand a real chance of crashing.

Given the tradeoffs, we're accepting the risk.

@jwz and there's room for iteration here. If we find out there are 3rd party armhf binaries that can't be rebuilt for this, we can certainly work with relevant library upstreams to provide compatibility.

@vorlon But those binaries will always exist. There's going to be something in /usr/local/ that I built from source years ago and didn't know I needed to recompile after doing a system upgrade; or something I installed as a binary whose maintainer has gone AWOL. In those cases I would absolutely prefer to have the program fail to launch with a link error, than for it to just go YOLO and smash the stack days later. That's not what I'd consider failing safe.

@jwz you're not wrong. There just aren't many options for handling this kind of ABI problem at scale.

It's further mitigated by the fact that most of these libraries will also have upstream soname changes between one stable Debian release and the next.

This kind of thing (transitions where we keep the upstream soname but the ABI changes in a possibly crashing way) is also not really new. This time only the scale is different.

jwz

@vorlon And this isn't just about 32 bit architectures, right? On aarch64/bookworm I get a 32 bit time_t unless I defined _TIME_BITS=64, so that binary would fail weird if some library it called changed its signature.

I feel like what you want is: every library that uses a type whose size has changed, also has to do the "64 symbol suffix" trick that glibc did. I can't guess know how big that set is, but it at least sounds statically computable.

@jwz the aarch64 ABI uses 64-bit time_t already. No ABI change for 64-bit archs.

@vorlon But I just tried it!

cat > a.c
<time.h>
<stdio.h>
int main(int ac, char **av) { printf("%d\n",sizeof(time_t)); }
^D
gcc -Wall a.c && ./a.out ; arch
4
aarch64

@jwz um double checking here

@jwz
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="debian.org/"
SUPPORT_URL="debian.org/support"
BUG_REPORT_URL="bugs.debian.org/"
$ cat > a.c
<time.h>
<stdio.h>
int main (int argc, char **argv)
{
printf("%d\n", sizeof(time_t));
}
^D
$ $ gcc -o time-t-check a.c && ./time-t-check; arch
8
aarch64
$

not reproducible here.

www.debian.orgDebian -- The Universal Operating SystemDebian is an operating system and a distribution of Free Software. It is maintained and updated through the work of many users who volunteer their time and effort.

@vorlon Huh. This is 12.1 on a Pi 4b, but the "raspbian.org" fork, so maybe they did something weird.

@jwz ah that explains, actually. `arch` after all is really just returning the *kernel* architecture (equivalent to `uname -m`). Raspbian only provides armhf as an architecture, they just happen to also provide a 64-bit kernel with it which is what you're running. Your time_t is 32-bit because your gcc target as a whole is 32-bit. See also `dpkg --print-architecture`.

@vorlon Ok, well that's all confusing and awful! I do not envy anyone dealing with this. But I think it actually argues in favor of "force linking to break if sizes changed", because apparently $VERSION doesn't really mean anything....

@jwz would it be better if software failed at start if the ABI is incompatible? Sure!
Do I as a distribution developer have a way to implement this in a cross-cutting fashion across 1200 upstream library projects without also breaking binary compatibility everywhere else that's not affected? I do not!

The glibc solution is wonderful. It is also the work of an upstream team who have an unwavering commitment to maintaining both binary compatibility and source compatibility (with C standards).
1/2

@jwz glibc accomplishes this because they have a build system tailor-made for handling it, something they've done many times before (glibc has not broken binary compatibility this millennium). It's also idiosyncratic, with a lot of this stuff not written in C at all, but metaprogramming using a custom build system.

If our plan for 2038 was to have each upstream project deliver what glibc did, we wouldn't be done until after 2038.
2/2