4 ms·

This is a Linux problem not a SBCL one. You could move your SBCL binary between different versions of a BSD variant.

by rjsw 3y ago

ducktective 3y ago
How come it's not a Go/Rust problem?
- rjsw 3y ago
  Go makes syscalls directly, it doesn't call through the system libc. This does cause support problems on at least NetBSD, don't know what happens on FreeBSD or OpenBSD. The NetBSD backwards compatibility mechanism is to not change the arguments to an existing syscall, if there is a need to change something then a new syscall will be created and aliased to the old name in the system include files. Old binaries use the old syscall, those compiled after the new one has been added will use that. Languages that don't parse the system .h files like Go need conditional code for NetBSD.
matheusmoreira 3y ago
This is not a Linux problem. The Linux system call binary interface is documented as stable. It's user space libraries like glibc that break backwards compatibility. There's nothing Linux can do about that. I've written more about this here: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls
- kazinator 3y ago
  > It's user space libraries like glibc that break backwards compatibility. s/backward/forward/ The commlaint here is that the older glibc on Debian 11 doesn't run programs built against a newer glibc under Debian 12. glibc has very good backward compatibility, with careful symbol versioning and whatnot. Backward compatibility means that a newer glibc (like in Debian 12) will handle programs requesting the older glibc (e.g. from Debian 11).
  - GrumpySloth 3y ago
    > glibc has very good backward compatibility, with careful symbol versioning and whatnot. Not in my experience. Working through exercises in Practical Binary Analysis, the first problem I needed to solve was running programs compiled against an older glibc on older Ubuntu on a new Ubuntu version with newer glibc, which boiled down to hunting down the glibc so from the older Ubuntu. Without it, the programs crashed on startup. That problem wasn’t even planned by the book author, but it sure was a good thematic fit. :)

This is a Linux problem not a SBCL one. You could move your SBCL binary between different versions of a BSD variant.

by rjsw 3y ago

This is a Linux problem not a SBCL one. You could move your SBCL binary between different versions of a BSD variant.

ducktective 3y ago

How come it's not a Go/Rust problem?

rjsw 3y ago
Go makes syscalls directly, it doesn't call through the system libc. This does cause support problems on at least NetBSD, don't know what happens on FreeBSD or OpenBSD. The NetBSD backwards compatibility mechanism is to not change the arguments to an existing syscall, if there is a need to change something then a new syscall will be created and aliased to the old name in the system include files. Old binaries use the old syscall, those compiled after the new one has been added will use that. Languages that don't parse the system .h files like Go need conditional code for NetBSD.

matheusmoreira 3y ago

This is not a Linux problem. The Linux system call binary interface is documented as stable. It's user space libraries like glibc that break backwards compatibility. There's nothing Linux can do about that. I've written more about this here: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls

kazinator 3y ago
> It's user space libraries like glibc that break backwards compatibility. s/backward/forward/ The commlaint here is that the older glibc on Debian 11 doesn't run programs built against a newer glibc under Debian 12. glibc has very good backward compatibility, with careful symbol versioning and whatnot. Backward compatibility means that a newer glibc (like in Debian 12) will handle programs requesting the older glibc (e.g. from Debian 11).
- GrumpySloth 3y ago
  > glibc has very good backward compatibility, with careful symbol versioning and whatnot. Not in my experience. Working through exercises in Practical Binary Analysis, the first problem I needed to solve was running programs compiled against an older glibc on older Ubuntu on a new Ubuntu version with newer glibc, which boiled down to hunting down the glibc so from the older Ubuntu. Without it, the programs crashed on startup. That problem wasn’t even planned by the book author, but it sure was a good thematic fit. :)