`pthread_mutex_t` varies across architectures, in several ways:
- endianness alters the ordering of bytes, since the contents of the
  struct are larger than 8-bit.
- its length varies.
- the location of the mutex kind (`PTHREAD_MUTEX_RECURSIVE`,
  `PTHREAD_MUTEX_ERRORCHECK` or `PTHREAD_MUTEX_ADAPTIVE_NP`) varies
  between 32-bit and 64-bit: On 32-bit architectures, it is preceded by
  three int/unsigned int, while on 64-bit architectures, it is preceded
  by four of them.

These initializers are only available from <pthread.h> when _GNU_SOURCE
is defined.

Relax the cfg_if check in ci/style.rs to allow #[cfg(target_endian)]
tests.

The libc crate is used as a dependency of the Rust compiler. Its build
system passes `--cfg dox` to all crates when generating their
documentation. libc's documentation is generated when the build system
is asked to generate the compiler documentation because `cargo doc`
automatically documents all dependencies.

When the dox configuration option is enabled, libc disables its
dependency on the core crate and provides the necessary definitions
itself. The dox configuration option is meant for generating
documentation for a multitude of targets even if the core crate for that
target is not installed. However, when documenting the compiler, it's
not necessary to do that; we can just use core or std as usual.

This change is motivated by the changes made to the compiler in
rust-lang/rust#48171. With these changes, it's necessary to provide
implementations of the Clone and Copy traits for some primitive types in
the library that defines these traits (previously, these implementations
were provided by the compiler). Normally, these traits (and thus the
implementations) are provided by core, so any crate that uses
`#![no_core]` must now provide its own copy of the implementations.

Because libc doesn't provide its own copy of the implementations yet,
and because the compiler's build system passes `--cfg dox` to libc,
generating the documentation for the compiler fails when generating
documentation for libc. By renaming the configuration option, libc will
use core or std and will thus have the necessary definitions for the
documentation to be generated successfully.

Looks like ubuntu 17.04 is broken now and it fails to link on 17.10 and 18.04.
It seems to work on stretch though!

Apparently 17.04 is broken now?

Looks like `cargo test` is now trying to test too many files due to
rust-lang/cargo#4750 so add a clause to the wrapper to ignore the bogus ones for
now

It wasn't expecting a `*.d` file to exist, now it does.

Pure sh scripts should use /bin/sh as it's available on every platform.

When using bash-specific features, use env to find it, as bash can
be installed in different places according the OS.

* Add syscall tables to most remaining arches in `src/unix/notbsd`
* Add aarch64/arm musl to CI
* Update dependencies

Apparently it no longer works

Signed-off-by: Tom Kirchner <tjk@amazon.com>
Signed-off-by: Ben Cressey <bcressey@amazon.com>

Apparently the 17.10 image broke?

Rebase of #610 and also move emscripten up much higher in the hierarchy to
ensure that it doesn't have too much of a ripple effect on other platforms.

This involved moving down a good number of definitions, but hopefully was done
with care to not break anything!

This works by specifying a "runner" for actually executing the binary.
This doesn't apply to the Android or NetBSD runs because there
isn't a simple binary that just runs the executable.

We now create an additional binary `linux_fcntl` for testing this
since there are header conflicts when including all necessary headers.
This binary is run on all platforms even though it's empty on all non-
Android/non-Linux platforms.

Testing has been switched from a custom binary to using a runner-less
test (or pair of tests). This means that for local development a simple
`cd libc-test && cargo test` will run all the tests. CI has also been
updated here to reflect that.

It's now broken due to changes in the `gcc` crate and having a too-old compiler,
and in general it's unfortunately architecturally so different from the other
test frameworks that it's difficult to maintain over time.

We can't test s390x because qemu segfaults but we can at least verify that it
compiles.

Closes #650