7 ms·

Depending on the operating system, you can't skip libc even in Go. I think it's required on openbsd and illumos/solaris for example. https://utcc.utoronto.ca/~

Depending on the operating system, you can't skip libc even in Go. I think it's required on openbsd and illumos/solaris for example. https://utcc.utoronto.ca/~cks/space/blog/programming/Go116OpenBSDUsesLibc https://utcc.utoronto.ca/~cks/space/blog/programming/Go116Op...

favorited 3y ago
golang used to break all the time on macOS, because it was using the syscall ABI, which isn't stable, instead of libSystem, which is.
- dottedmag 3y ago
  It has been fixed recently-ish.
  - littlestymaar 3y ago
    A long time ago, but AFAIK the fix was “use the system's libc”.
  - bananapub 3y ago
    it was fixed by using-the-system-libs
  - eatonphil 3y ago
    Could you link to the fix or their docs on it? I.e. what do they do today?
    - favorited 3y ago
      The comments on this GitHub issue include links to the changes in the golang code review system: https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490
beebmam 3y ago
I think it's the same in Windows, right? Can't use the syscalls underneath the hood, everything through the standard libraries. Maybe I'm wrong (I know very little about Windows other than how to use it to play games, and WSL)
- roblabla 3y ago
  On windows it’s somewhat possible to avoid most of it by linking to ntdll, which only provides symbols for raw syscall wrappers. But a lot of it is unstable and may change from a windows release to the next. Doing raw syscalls without ntdll is also possible, but windows syscall numbers change on essentially every release, so you’d end up with something that only works on your windows version.
- ynik 3y ago
  The standard libraries on Windows don't involve libc. The Windows APIs look rather different, and in general are much more friendly to multi-threading. POSIX on the other hand tends to assume that the program is in control of everything happening inside of it, which is an incorrect assumption due to libraries. In this particular case, the Windows APIs have neither getaddrinfo() nor getenv(); and the closest equivalent GetEnvironmentVariableW is perfectly thread-safe. Microsoft additionally has a C runtime (msvcrt) providing functions like getenv(), but this is much less fundamental than it is on other system. Every program is supposed to ship its own copy of the C runtime, it's not officially part of Windows! And it's perfectly possible for multiple different copies of the C runtime to be loaded into the same Windows process. And since *environ is a variable defined by the C runtime, there's a different copy for each C runtime...
  - pjmlp 3y ago
    Almost correct, except that since Windows 10 there is now a C runtime shipped as standard, ironically it is actually written in C++ taking advantage of its safety features over plain C, and exposing the C API via extern "C". https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170 https://learn.microsoft.com/en-us/cpp/windows/universal-crt-...

favorited 3y ago

golang used to break all the time on macOS, because it was using the syscall ABI, which isn't stable, instead of libSystem, which is.

dottedmag 3y ago
It has been fixed recently-ish.
- littlestymaar 3y ago
  A long time ago, but AFAIK the fix was “use the system's libc”.
- bananapub 3y ago
  it was fixed by using-the-system-libs
- eatonphil 3y ago
  Could you link to the fix or their docs on it? I.e. what do they do today?
  - favorited 3y ago
    The comments on this GitHub issue include links to the changes in the golang code review system: https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490

beebmam 3y ago

I think it's the same in Windows, right? Can't use the syscalls underneath the hood, everything through the standard libraries. Maybe I'm wrong (I know very little about Windows other than how to use it to play games, and WSL)

roblabla 3y ago
On windows it’s somewhat possible to avoid most of it by linking to ntdll, which only provides symbols for raw syscall wrappers. But a lot of it is unstable and may change from a windows release to the next. Doing raw syscalls without ntdll is also possible, but windows syscall numbers change on essentially every release, so you’d end up with something that only works on your windows version.
ynik 3y ago
The standard libraries on Windows don't involve libc. The Windows APIs look rather different, and in general are much more friendly to multi-threading. POSIX on the other hand tends to assume that the program is in control of everything happening inside of it, which is an incorrect assumption due to libraries. In this particular case, the Windows APIs have neither getaddrinfo() nor getenv(); and the closest equivalent GetEnvironmentVariableW is perfectly thread-safe. Microsoft additionally has a C runtime (msvcrt) providing functions like getenv(), but this is much less fundamental than it is on other system. Every program is supposed to ship its own copy of the C runtime, it's not officially part of Windows! And it's perfectly possible for multiple different copies of the C runtime to be loaded into the same Windows process. And since *environ is a variable defined by the C runtime, there's a different copy for each C runtime...
- pjmlp 3y ago
  Almost correct, except that since Windows 10 there is now a C runtime shipped as standard, ironically it is actually written in C++ taking advantage of its safety features over plain C, and exposing the C API via extern "C". https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170 https://learn.microsoft.com/en-us/cpp/windows/universal-crt-...