Description
Inevitably, when depending on a lot of crates, you'll find you have a dependency on libc. This issue tracks what can be done in such cases for platforms that don't have a native libc.
An implementation of the libc API in Rust: https://github.com/redox-os/relibc
libc crate
Some crates might depend directly on the libc crate. That's probably the case because std doesn't directly expose the needed functionality. Currently using this on a non-C platform this means you'll need to maintain a fork of those crates implementing the functionality another way, or just removing the affected functionality all together. You might have to maintain those forks too, since not all upstream crates are amenable to upstreaming such changes (see e.g. rand, chrono, yasna).
C types only
Some crates depend on the libc crate only for platform-specific type definitions, such as c_void or intptr_t. These types are not really part of libc, but rather of the standard C ABI for a platform. Some, but not all, types are also defined in std::os::raw, which has been mentioned as a candidate for deprecation. An RFC to pull such types into a separate crate failed, although the it seems likely that it could be revived now that extern type is implemented.
C libraries
Other types of crates might depend on C libraries that themselves depend on libc. My strategy there so far has been to
- Copy parts of musl C for things that are just pure computation (
strcmp, etc.) - Comprehensively edit the C source to modify/remove I/O related stuff to better work with Rust primitives (
connect,printf, etc.) - Implement some functions directly in Rust as
#[no_mangle] extern "C" fns (malloc, etc.)
This is also a lot of work.