Open jethrogb opened 6 years ago
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.
@aturon's comment (https://github.com/rust-lang/rfcs/pull/1783#issuecomment-290251562) deciding to close https://github.com/rust-lang/rfcs/pull/1783# actually has a fairly compatible plan:
(1) redefine
c_void
everywhere in terms of such a type, making all instances interchangeable, (2) deprecatestd::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.
Would the work happening on https://github.com/redox-os/relibc help or overlap at all?
@jesselucas whoops, yes, I meant to link to that, thanks.
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 nativelibc
.An implementation of the
libc
API in Rust: https://github.com/redox-os/relibclibc
crateSome crates might depend directly on the
libc
crate. That's probably the case becausestd
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 asc_void
orintptr_t
. These types are not really part oflibc
, but rather of the standard C ABI for a platform. Some, but not all, types are also defined instd::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 thatextern 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 tostrcmp
, etc.)connect
,printf
, etc.)#[no_mangle] extern "C" fn
s (malloc
, etc.)This is also a lot of work.