this post was submitted on 29 Sep 2024
100 points (100.0% liked)

Linux

48186 readers
1365 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Markaos@lemmy.one 1 points 1 month ago (1 children)

Your argument is to have 2 subtly incompatible abis and one day binaries magically break.

Whereas your argument seems to be to have a special C variant for 32bit Linux - there's no reason to have a special time64_t anywhere else.

No program with time32_t will ever work after 2038, so any compiled that way are broken from compilation.

Yeah, so what will breaking the ABI do? Break it a bit more?

If you really want to be clever, mangle the symbols for the functions that handle time so they encode time64 as appropriate

That's what MUSL libc does, and the result is two subtly incompatible ABIs - statically linked programs are fine, but if a dynamically linked library exports any function with time_t parameter or return value, it will use whatever size was configured at build time and it becomes a part of its ABI. So fixing this properly would require every library that wants to pass time_t values in its API to implement its own name mangling. That's not a reasonable request for a barely used platform (remember, this is just 32bit userland, 64bit was always unaffected).

[–] InverseParallax@lemmy.world 0 points 1 month ago (1 children)

Great, then we just leave everything alone and say 32-bit user land is broken past 2038, doubt too many people are dying to run 32-bit userland after that, but if they are I can guarantee they'll be running old binaries probably without source.

[–] racketlauncher831@lemmy.ml 1 points 1 month ago (1 children)

I might be selfish for saying so, but if anyone set up their mind to run anything on a 32-bit system after 2038, they must care enough to compile themselves, right? Any binaries compiled today will be EOL by then.

[–] InverseParallax@lemmy.world 2 points 1 month ago

I think this is a reasonable assumption, but my experience suggests it will absolutely not be true for a lot of proprietary software.

That being said, that stuff will only be supported on rhel which will bend over backwards to keep it sort of working somehow.