4 ms·

Lol, that only works if you can force everyone on the platform to go along with it. It is a nice solution, but it requires you to control the c library. Gentoo

by db48x 2y ago

Lol, that only works if you can force everyone on the platform to go along with it. It is a nice solution, but it requires you to control the c library. Gentoo doesn’t control what libc does; that’s either GNU libc or MUSL or some other thing that the user wants to use.

dmitrygr 2y ago
> requires you to control the c library Which is why basically every other same operating system does that. BSDs, macOS, WinNT. Having the stable boundary be the kernel system call interface is fucking insane. And somehow the Linux userspace people keep failing to learn this lesson, no matter how many times they get clobbered in the face by the consequences of not learning it.
- eschaton 2y ago
  And yet it would still work out for Linux if musl, glibc, et al just adopted `API_VERSION_MIN` and `API_VERSION_MAX` macros themselves, it doesn’t actually have to be handled entirely at the `-isysroot` level.
- db48x 2y ago
  It’s extra work, but I don’t know that it is necessarily insane. If libc was under the complete control of the kernel developers, then that gives other languages fewer options. Go famously (or infamously) uses certain syscalls without going through libc, for example. Sometimes the choices made for the C library just aren’t compatible with other languages. Frankly the C library, as it exists today, is insane. Maybe the solution is to split it in half: one for the syscalls and another for things like strings and environment variables and locales and all the other junk.
  - mort96 2y ago
    Splitting libc into one "stable kernel API" part and one "library with things which are useful to C programmers" part would honestly make a ton of sense. OSes which declare their syscall interface to be unstable would be more convincing if they actually provided a stable API that's intended for other consumers than C.
    - AshamedCaptain 2y ago
      Frankly I don't see the point of complaining that libc is not useful for non-C consumers. Sure, there are some ancillary functions in libc you'll likely never call. But what's the issue with making syscalls through libc? Again, the only difference is what the very last call instruction is. If your runtime can marshal arguments for the kernel, then it surely can marshal arguments for libc. They are almost always practically the same ABI. And you can avoid the need for VDSO-like hacks which is basically the kernel exposing a mini-libc to userspace.
      - db48x 2y ago
        This is the reason why Rust compiles every program statically, except that the resulting “static” binary still has to link against libc.
        account42 2y ago
        Graphical programs also have to link against libGL which also means linnking against libc, same for many other system libraries that make no sense to reimplement in your NIH language.
- clhodapp 2y ago
  Making the stable boundary be C headers is insane! It means that there's not actually any sort of ABI, only a C source API.
  - westurner 2y ago
    cibuildwheel builds manylinux packages for glibc>= and musl because of this ABI. manylinux: https://github.com/pypa/manylinux https://github.com/pypa/manylinux : > Python wheels that work on any linux (almost) Static Go binaries that make direct syscalls and do not depend upon libc or musl run within very minimal containers. Fuschia's syscall docs are nice too; Linux plus additional syscalls.
  - kazinator 2y ago
    Headers can do the magic to select the right ABI more or less transparently, based on preprocessor symbols which indicate the selection: is a certain type 32 or 64. This is similar to what Microsoft did in Win32 with the W and A functions (wide char and ascii/ansi). You just call MessageBox and the header file will map that to MessageBoxA or MessageBoxW based on whether you are a UNICODE build. The character element type in the strings accepted by MessageBox is TCHAR. That can either be CHAR or WCHAR. Once the code is compiled, it depends on the appropriate ABI: MessageBoxA or MessageBoxW; MessageBox doesn't exist; it is a source-level fiction, so to speak.
- AshamedCaptain 2y ago
  > no matter how many times they get clobbered in the face by the consequences of not learning it. While I do think that the boundary should be set at the libc level just out of design cleanliness, I fail to see what the "consequence" of not doing so is. You're just changing the instruction binaries use for syscalls from a relative jump to a trap (or whatever), but you still have all the problems with data type sizes, function "versions" and the like which are what this discussion is about.
  - dmitrygr 2y ago
    > I fail to see what the "consequence" of not doing so is. TFA ?
    - AshamedCaptain 2y ago
      No. How would it benefit TFA _at all_? For all practical purposes Linux currently has _two_ stable boundaries, libc (glibc) and kernel. If you move it so that the stable boundary is only the kernel, you still have this problem. If you move it so that the stable boundary is only libc, you still have this problem. In fact, TFA's problem comes from applications passing time_ts around, which is strictly a userspace problem, and the syscall interface is almost entirely ortogonal. Heck, the 32-bit glibc time_t functions probably use the 64-bit time_t syscalls these days...
- asveikau 2y ago
  > WinNT This isn't true. There is an msvcrt in the OS, but it's mainly there for binaries that are part of Windows. The CRT is released as part of Visual Studio, out of band from the Windows release schedule. Although CRT's place is in the layering a little different, because of so many things talking directly to Windows APIs.
  - dmitrygr 2y ago
    IIRC, the CRT in windows makes NO system calls. Those are all in ntdll.dll, and in ntdll.dll ONLY
    - asveikau 2y ago
      That's just a legacy of the strategy where NT native APIs were considered a private API, and you were meant to code against Win32 instead, to target both NT and 9x. Syscalls are in ntdll, layered above that is kernel32 (today kernelbase), then most user mode code including CRT is above that. In 9x kernel32 were syscalls, in NT they were user mode shims above ntdll. That's for most things. Things like gdi have kernel entry points too afaik. Anyway my point is that the C library is developed out of band from that.
- deleted 2y ago
  [deleted]
eschaton 2y ago
It’s entirely opt-in, Apple doesn’t force it. If you just do `cc mything.c -o mything` you get a binary whose minimum required OS is the version of the SDK you built it against, just as with any other UNIX-like OS. It’s just giving the developer the option to build something they know will run on an earlier version too. And since it was all initially done with the preprocessor rather than adding knowledge to the compilers, there’s no reason individual libraries can’t handle API versioning in exactly this way, including things like differing `ino_t` and `off_t` sizes.

by db48x 2y ago

dmitrygr 2y ago

> requires you to control the c library Which is why basically every other same operating system does that. BSDs, macOS, WinNT. Having the stable boundary be the kernel system call interface is fucking insane. And somehow the Linux userspace people keep failing to learn this lesson, no matter how many times they get clobbered in the face by the consequences of not learning it.

eschaton 2y ago
And yet it would still work out for Linux if musl, glibc, et al just adopted `API_VERSION_MIN` and `API_VERSION_MAX` macros themselves, it doesn’t actually have to be handled entirely at the `-isysroot` level.
db48x 2y ago
It’s extra work, but I don’t know that it is necessarily insane. If libc was under the complete control of the kernel developers, then that gives other languages fewer options. Go famously (or infamously) uses certain syscalls without going through libc, for example. Sometimes the choices made for the C library just aren’t compatible with other languages. Frankly the C library, as it exists today, is insane. Maybe the solution is to split it in half: one for the syscalls and another for things like strings and environment variables and locales and all the other junk.
- mort96 2y ago
  Splitting libc into one "stable kernel API" part and one "library with things which are useful to C programmers" part would honestly make a ton of sense. OSes which declare their syscall interface to be unstable would be more convincing if they actually provided a stable API that's intended for other consumers than C.
  - AshamedCaptain 2y ago
    Frankly I don't see the point of complaining that libc is not useful for non-C consumers. Sure, there are some ancillary functions in libc you'll likely never call. But what's the issue with making syscalls through libc? Again, the only difference is what the very last call instruction is. If your runtime can marshal arguments for the kernel, then it surely can marshal arguments for libc. They are almost always practically the same ABI. And you can avoid the need for VDSO-like hacks which is basically the kernel exposing a mini-libc to userspace.
    - db48x 2y ago
      This is the reason why Rust compiles every program statically, except that the resulting “static” binary still has to link against libc.
      - account42 2y ago
        Graphical programs also have to link against libGL which also means linnking against libc, same for many other system libraries that make no sense to reimplement in your NIH language.
clhodapp 2y ago
Making the stable boundary be C headers is insane! It means that there's not actually any sort of ABI, only a C source API.
- westurner 2y ago
  cibuildwheel builds manylinux packages for glibc>= and musl because of this ABI. manylinux: https://github.com/pypa/manylinux https://github.com/pypa/manylinux : > Python wheels that work on any linux (almost) Static Go binaries that make direct syscalls and do not depend upon libc or musl run within very minimal containers. Fuschia's syscall docs are nice too; Linux plus additional syscalls.
- kazinator 2y ago
  Headers can do the magic to select the right ABI more or less transparently, based on preprocessor symbols which indicate the selection: is a certain type 32 or 64. This is similar to what Microsoft did in Win32 with the W and A functions (wide char and ascii/ansi). You just call MessageBox and the header file will map that to MessageBoxA or MessageBoxW based on whether you are a UNICODE build. The character element type in the strings accepted by MessageBox is TCHAR. That can either be CHAR or WCHAR. Once the code is compiled, it depends on the appropriate ABI: MessageBoxA or MessageBoxW; MessageBox doesn't exist; it is a source-level fiction, so to speak.
AshamedCaptain 2y ago
> no matter how many times they get clobbered in the face by the consequences of not learning it. While I do think that the boundary should be set at the libc level just out of design cleanliness, I fail to see what the "consequence" of not doing so is. You're just changing the instruction binaries use for syscalls from a relative jump to a trap (or whatever), but you still have all the problems with data type sizes, function "versions" and the like which are what this discussion is about.
- dmitrygr 2y ago
  > I fail to see what the "consequence" of not doing so is. TFA ?
  - AshamedCaptain 2y ago
    No. How would it benefit TFA _at all_? For all practical purposes Linux currently has _two_ stable boundaries, libc (glibc) and kernel. If you move it so that the stable boundary is only the kernel, you still have this problem. If you move it so that the stable boundary is only libc, you still have this problem. In fact, TFA's problem comes from applications passing time_ts around, which is strictly a userspace problem, and the syscall interface is almost entirely ortogonal. Heck, the 32-bit glibc time_t functions probably use the 64-bit time_t syscalls these days...
asveikau 2y ago
> WinNT This isn't true. There is an msvcrt in the OS, but it's mainly there for binaries that are part of Windows. The CRT is released as part of Visual Studio, out of band from the Windows release schedule. Although CRT's place is in the layering a little different, because of so many things talking directly to Windows APIs.
- dmitrygr 2y ago
  IIRC, the CRT in windows makes NO system calls. Those are all in ntdll.dll, and in ntdll.dll ONLY
  - asveikau 2y ago
    That's just a legacy of the strategy where NT native APIs were considered a private API, and you were meant to code against Win32 instead, to target both NT and 9x. Syscalls are in ntdll, layered above that is kernel32 (today kernelbase), then most user mode code including CRT is above that. In 9x kernel32 were syscalls, in NT they were user mode shims above ntdll. That's for most things. Things like gdi have kernel entry points too afaik. Anyway my point is that the C library is developed out of band from that.
deleted 2y ago
[deleted]

eschaton 2y ago

It’s entirely opt-in, Apple doesn’t force it. If you just do `cc mything.c -o mything` you get a binary whose minimum required OS is the version of the SDK you built it against, just as with any other UNIX-like OS. It’s just giving the developer the option to build something they know will run on an earlier version too. And since it was all initially done with the preprocessor rather than adding knowledge to the compilers, there’s no reason individual libraries can’t handle API versioning in exactly this way, including things like differing `ino_t` and `off_t` sizes.