- Mar 27, 2019
-
-
Alex Crichton authored
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]:
-
- Mar 26, 2019
- Mar 25, 2019
- Mar 11, 2019
-
-
bors authored
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>
-
- Mar 08, 2019
-
-
Yu Ding authored
Signed-off-by:
Yu Ding <dingelish@gmail.com>
-
- Mar 05, 2019
-
-
bors authored
Bump to 0.2.50 I'm using libnx-rs too, and it'd be nice to have #1278 in a release.
-
- Mar 04, 2019
-
-
leo60228 authored
-
- Mar 03, 2019
-
-
bors authored
Upgrade bunch of EOL docker images to Ubuntu 18.04 When upgrading other Dockerfiles (not modified in this PR) they fail with different errors: https://travis-ci.com/mati865/libc/jobs/181623075 https://travis-ci.com/mati865/libc/jobs/181623059 https://travis-ci.com/mati865/libc/jobs/181623067 I think it's because of these 2 commits in glibc: https://sourceware.org/git/?p=glibc.git;a=commit;h=b05cb613e7ae507680c8d914b3e788eea782c0d6 https://sourceware.org/git/?p=glibc.git;a=commit;h=2dba5ce7b8115d6a2789bf279892263621088e74 I have no idea how to fix them so leaving it for somebody who knows what to do.
-
bors authored
Check that more targets build
-
gnzlbg authored
-
gnzlbg authored
-
gnzlbg authored
-
Mateusz Mikuła authored
-
Mateusz Mikuła authored
-
bors authored
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".
-
Stefan Lankes authored
-
bors authored
x86_64-uclibc-l4re: fix syntax error + linter issues - fix syntax error in expand_align macro - fix errors due to doubly defined symbols / functions for x86_64-uclibc
-
Stefan Lankes authored
-
Stefan Lankes authored
-
bors authored
vm_size_t does not exist on OpenBSD and Bitrig unbreak openbsd and bitrig after #1294 r? @gnzlbg
-
Stefan Lankes authored
-
Sébastien Marie authored
-
Stefan Lankes authored
-
bors authored
Add vm_size_t
-
Guillaume Gomez authored
-
- Mar 02, 2019
-
-
Stefan Lankes authored
-
Stefan Lankes authored
-
Sebastian Humenda authored
-
Sebastian Humenda authored
- fix syntax error in expand_align macro - fix errors due to doubly defined symbols / functions for x86_64-uclibc
-
bors authored
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.
-
Stefan Lankes authored
-
Stefan Lankes authored
-
Sébastien Marie authored
while here, generate the right file in test_openbsd()
-
bors authored
Link docs for other platforms in docs.rs
-
gnzlbg authored
-
bors authored
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.
-
- Mar 01, 2019
-
-
gnzlbg authored
-