3 ms·

As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. In fact, Linux offers nolibc.h as a nice header to get

As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. In fact, Linux offers nolibc.h as a nice header to get just syscalls and extremely basic functions like memcpy and strlen. The most up to date source at the moment is https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/tree/tools/include/nolibc/nolibc.h?h=dev https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linu... AFAIK (the linus master tree was missing some necessary fixes for x86_64 last I checked). On Windows, it is somewhat laborious and involves some debatable trade-offs, but you can avoid msvcrt/ucrt altogether but you must link with kernel32 for syscalls. I have a very minimal nomsvcrt.h that just defines types and externs for those syscalls defined in kernel32, but it's really incomplete -- it's easy to write your own based on win32 docs anyway. One additional thing you'll need though are all the compiler bits that are now missing, mostly dealing with floating point conversions. https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows https://hero.handmade.network/forums/code-discussion/t/94-gu... provides an excellent guide, but note the trade-offs made. I think the last thing you might want is a routine to turn GetCommandLineA()'s result into argc, *argv[], and if you can use LGPL, that's available in https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/exe_entry.c https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winec... I don't have a macOS system right now, but I'm willing to bet there's a similar scheme possible there. That covers a lot of systems. OpenBSD is the only system I know of that really enforces system calls to go through their libc, but I'm ignorant.

account42 5y ago
> As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. Unless you want to use graphics acceleration, which is implemented in userspace as harware-specific dynamic libraries. Audio also typically goes through user-space implementations - not sure if the interprocess protocols there are stable enough to statically the client libraries.
- dundarious 5y ago
  Definitely, was just describing the base level reality that you can in theory just use syscalls and skip libc. In practice, that doesn't mean there are "enough" useful kernel interfaces or graphics libraries implemented right now that also skip libc. Much like how there might not be enough no_std compatible crates available in rust. For systems programming, I find nolibc and kernel32 adequate.

account42 5y ago

> As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. Unless you want to use graphics acceleration, which is implemented in userspace as harware-specific dynamic libraries. Audio also typically goes through user-space implementations - not sure if the interprocess protocols there are stable enough to statically the client libraries.

dundarious 5y ago
Definitely, was just describing the base level reality that you can in theory just use syscalls and skip libc. In practice, that doesn't mean there are "enough" useful kernel interfaces or graphics libraries implemented right now that also skip libc. Much like how there might not be enough no_std compatible crates available in rust. For systems programming, I find nolibc and kernel32 adequate.