You always compile for a specific machine. There is always a target instruction set architecture. It decides the calling convention used for Linux system calls. Compiler can even produce an error in case the target is not supported by Linux.
> In general you are compiling for some abstract notion of an OS.
This "abstract notion of an OS" boils down to the libc. Freestanding C gets rid of most of it. Making system calls is also perfectly valid in hosted C. Modern languages like Rust also have freestanding modes.
> In my experience there are often detailed explanation in the notes section.
That's the problem. Why is the Linux stuff just a bunch of footnotes in the Linux manual? It should be in the main section. The glibc specifics should be footnotes.
Abstract notion of OS meaning Debian 12. Not Linux kernel commit ####, GNU libc commit ####, dpkg commit ####, apt commit ####, Apache httpd commit #### with patch ### to ### from Debian 4 version ### and Ubuntu 21 version ###, SQLite3 with special patches ### installed in /opt/bin/foo, ... (you get the idea).
> That's the problem. Why is the Linux stuff just a bunch of footnotes in the Linux manual? It should be in the main section. The glibc specifics should be footnotes.
Because you look at the OS manual, not at the documentation of the kernel. Notes and Bugs are also not footnotes in man pages. They are pretty important and are basically the first free-form section where you can tell about the ideas, ideals and history. The first part a pretty strict, formal description of the calling semantics.
Compilers build for target triples such as x86_64-linux-gnu. It is of the form isa-kernel-userspace. If kernel is linux, the builtin can be used. The isa determines the code generated by the compiler, both in general and for the builtin. The userspace can be anything at all, including none. Sometimes compilers build for target quadruples which also include a vendor, and that information is also irrelevant.
Modifying the OS is fine, if this is what you want to do, but it comes with tradeoffs.
----
You wrote earlier:
> actually tried to hack a linux_system_call builtin into GCC at some point. [...] The maintainers didn't seem too convinced in the mailing list so I didn't bother rewriting it.
I am not sure what exactly this means. There is syscall(2) in the libc, if you want to do this. If you want to inline the wrappers you can pass -static to the compiler invocation.
If it ever breaks, it's a bug in the Linux kernel.
> It will also break when a user uses the OS configuration to change the behaviour of some OS functionality
Can you give concrete examples of this?
> There is syscall(2) in the libc, if you want to do this.
I know. I've written my own syscall(), as well. The idea is to put it in the compiler as a builtin so there's no need to even write it.
No, your program will still instruct the kernel to do the same. It will just cause conflicts with the other OS internals.
> Can you give concrete examples of this?
Adding another encoding as a gconv module. The DNS issues everyone is talking about.
I don't know what that gets you compared to using syscall(2) and -static. When you want your program to depend on the kernel API instead of the OS API, then you should really link libc statically.
But not with the kernel.
"Other OS internals" are just replaceable components. The idea is to depend on Linux only, not on Linux+glibc.
> Adding another encoding as a gconv module. The DNS issues everyone is talking about.
Those are glibc problems, not Linux problems. Linux does not perform name resolution or character encoding conversion.