libc dependencies

[jethrogb]

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

1. Copy parts of musl C for things that are just pure computation (strcmp, etc.)
2. Comprehensively edit the C source to modify/remove I/O related stuff to better work with Rust primitives (connect, printf, etc.)
3. Implement some functions directly in Rust as #[no_mangle] extern "C" fns (malloc, etc.)

This is also a lot of work.

[panicbit]

This might be solved together with #1 IF we go the abstract_platform way.
See for example the ctypes or memchr.
Platform implementations can depend on whatever they want/need.

It might make sense to split some low-level primitives off into their own crate, such that you can depend on that instead of libc.

[Ericson2314]

@aturon's comment (rust-lang/rfcs#1783 (comment)) deciding to close rust-lang/rfcs#1783 actually has a fairly compatible plan:

(1) redefine c_void everywhere in terms of such a type, making all instances interchangeable, (2) deprecate std::os::raw, which would then be purely type aliases, and (3) introduce a ctypes crate on crates.io which provides canonical (and compatible) type aliases.

[jesselucas]

Would the work happening on https://github.com/redox-os/relibc help or overlap at all?

[jethrogb]

@jesselucas whoops, yes, I meant to link to that, thanks.

[jethrogb]

rust-lang/rust#52839

[jethrogb]

rust-lang/rfcs#2521