This target is [being proposed][LINK] int he rust-lang/rust repository
and this is intended to get coupled with that proposal. The definitions
here all match the upstream reference-sysroot definitions and the
functions all match the reference sysroot as well. The linkage here is
described more in detail on the Rust PR itself, but in general it's
similar to musl.
Automatic verification has been implemented in the same manner as other
targets, and it's been used locally to develop this PR and catch errors
in the bindings already written (also to help match the evolving sysroot
of wasi). The verification isn't hooked up to CI yet though because
there is no wasi target distributed via rustup just yet, but once that's
done I'll file a follow-up PR to execute verification on CI.
[LINK]:
Add essential target_vendor check for sgx
As discussed in issue [57231](https://github.com/rust-lang/rust/issues/57231), the current `sgx` branch only works for Fortanix's sgx platform. So the `target_vendor` should be checked here.
Signed-off-by: Yu Ding <dingelish@gmail.com>
add HermitCore support even if it doesn't have a UNIX interface
Currently, we redefine the interface between the HermitCore kernel (https://hermitcore.org) and Rust’s standard library. In the future, it will not depend on a POSIX-compatible C library. Consequently, we add the support of HermitCore if the "unix" environment isn’t set. It will be great to integrate this patch because it would simplify our development. The classical interface is still supported and part of the subdirectory "unix".
adjust PTHREAD_STACK_MIN to current value on OpenBSD
adjust `PTHREAD_STACK_MIN` to current value on OpenBSD, and while here, generate the right file in test_openbsd()
I should say that I am a bit disappointed. If I didn't miss anything, the related change for `PTHREAD_STACK_MIN` is near to one year old. And clearly with the name error in `test_openbsd()` something wasn't clean.
Verify that only non-technical breaking changes are applied to libc
Closes#270 .
cc @alexcrichton so this would be a solution to #270 that uses rust-semverver to check that the API of `libc` contains only non-technical breaking changes.
This is a WIP and uses a fork of `rust-semverver` for now, but I've sent PRs upstream already. This is the only idea I have for solving #270 . `rust-semverver` is not perfect, but it can deal with functions, consts, and simple structs just fine, and that's pretty much everything that libc uses.
cc @ibabushkin
Some other notes:
* we have to compile `rust-semverver` for each toolchain version, and it depends on `cargo` so we have to build ~160 dependencies. Using `cache: cargo` breaks everything.
Add arm-uclibc definitions
I used `buildroot-2017.05` to build armv7 cross compiler, `uclibc-1.0.24` and `libc-test`. I've executed `libc-test` on armv7-based SoC, using modified `libc-test` to account for the environment. Modified libc-test is not included in this PR because it is too dependent on cross compilation and execution environment.