Why do executables have a dependency on glibc?

Question

Is it because the Rust standard library calls kernel system calls through glibc? But isn't it not that difficult to write a system call wrapper in Rust itself?

Answer 1

When a language is based on C library, its library calls usually look like this:

Language API -> C API -> System API

When a language does not use C library, its library calls delegate directly to the system API:

Language API -> System API

When you have C API in the middle, the implementation of language API will be simpler to write because you almost won't need to write any OS-specific code. This, in turn, allows to make the language cross-platform more easily - you can just delegate to the cross-platform C library instead of thinking of how to use concrete platform-specific functions.

In principle nothing in Rust prevents you from dropping C library and using system calls directly. As you have noticed, Go does exactly that. However, dependency on libc wasn't deemed that burdensome by Rust developers to justify writing that much of platform-specific code in the standard library.

Answer 2

Libraries/binaries should not call the system call directly but always call the corresponding function:

• the binary can run on a different OS as long as the suitable low level libraries are implemented;
• you can override the library function using a LD_PRELOAD livrary.

POSIX defines an API at the library (function) level but does not mandate any kind of system call convention.

For example, the Wine project runs Windows programs by providing libraries which implements the Windows API on top of native libc. If you have a program making direct Windows system calls, Wine will not be able to do anything as Wine does not implement the system calls but only the Windows APIs at the library level.

Moreover, Rust calls many other things in libc and other libraries:

• malloc, free
• pthread_mutex, pthread_cond;
• strcmp, strlen, strncpy;
• qsort, bsearch.