Why are binaries dependent on glibc?
When a language is based on the C library, its library calls usually look like this:
Language API -> C API -> System API
When a language does not use the C library, its library calls the delegate directly in the system API:
Language API -> System API
When you have a C API in the middle, the language API implementation will be easier to write because you will hardly need to write any OS-specific code. This, in turn, makes the language cross-platform simpler - you can simply delegate to the cross-platform C library instead of thinking about how to use specific platform-specific functions.
Basically, nothing in Rust allows you to ditch the C library and use system calls directly. As you can see, Go does exactly that. However, reliance on libc was not considered burdensome by the Rust developers to justify writing most of the platform-specific code in the standard library.
source to share
Libraries / binaries should not call the system call directly, but always call the appropriate function:
- the binary can run on a different OS if the corresponding lower-level libraries are implemented;
- you can override the library function with
LD_PRELOAD
livrary.
POSIX defines an API at the library (function) level , but does not require any syscalling convention.
For example, the Wine project runs Windows programs by providing libraries that implement the Windows API on top of the built-in libc. If you have a program that makes direct Windows system calls, Wine cannot do anything, because Wine does not implement system calls, but only the Windows API at the library level.
Additionally, Rust calls many other things in libc and other libraries:
-
malloc
,free
-
pthread_mutex
,pthread_cond
; -
strcmp
,strlen
,strncpy
; -
qsort
,bsearch
.
source to share