> Go originally wanted to not have to link any system libraries, something that does not actually work
It does work on Linux, the only kernel that promises a stable binary interface to user space.
FreeBSD does as well, but old ABI versions aren't kept forever.
People have told me that before but I was unable to find official documentation of this fact. Can you point me to it? Closest I found is forum posts claiming the ABI compatibility is good.
When developing a small program for my Synology NAS in Go, I'm sure I had to target a specific version of glibc.
Probably because the networking libraries use it for name resolution. That's a choice the developers of the Go implementation made. It's not required.
Does it really tho? I've had address resolution break more than once in go programs.
That's because on Linux systems it's typical for domain name resolution to be provided by glibc. As a result, people ended up depending on glibc. They were writing GNU/Linux software, not Linux software.
https://wiki.archlinux.org/title/Domain_name_resolution
https://en.wikipedia.org/wiki/Name_Service_Switch
https://man.archlinux.org/man/getaddrinfo.3
This is user space stuff. You can trash all of this and roll your own mechanism to resolve the names however you want. Go probably did so. Linux will not complain in any way whatsoever.
Linux is the only kernel that lets you do this. Other kernels will break your software if you bypass their system libraries.
I mean, that is fine and all, but it doesn't really matter for making the software run correctly on systems that currently exist.
It works fine on current Linux systems. We can have freestanding executables that talk to Linux directly and link against zero system libraries.
It's just that those executables are going to have to resolve names all by themselves. Chances are they aren't going to do it exactly like glibc does. That may or may not be a problem.
Historically, when DNS breaks in a not-glibc environment, it's very often found to in fact be a violation of some standard by the not-glibc, rather than a program that fails to document a glibc dependency.
Just connect to the service running on localhost ...
I'm curious. Why isn't getaddrinfo implemented in a similar manner to the loaders that graphics APIs use? Shouldn't that functionality be the responsibility of whatever resolver has been installed?
That is how `getaddrinfo` works under GLIBC; it's called NSS. The problem (well, one of them) is the non-GLIBC implementations that say "we don't need no stinkin' loader!"
The problem is people delete glibc and are surprised when glibc features are missing.
The only point I'm making is: Linux does not require glibc.
Users and their programs usually do require glibc but that's their choice. It's not mandated. People could theoretically rewrite the entire Linux user space in pure freestanding Rust if they wanted to.
Name Service Switch is just a solution to a problem. There's no law that says Linux systems must have that system. Programs that depend on it will break if it's not there but that's not the fault of Linux.