Openbsd fix
put in several fixes for OpenBSD (one fix per commit).
testsuite ran on OpenBSD 6.3-current (upcoming 6.4)
```
RUNNING ALL TESTS
PASSED 6474 tests
```
Bump ctest from `482c7f0` to `5c53723`
Bumps [ctest](https://github.com/alexcrichton/ctest) from `482c7f0` to `5c53723`.
<details>
<summary>Commits</summary>
- [`5c53723`](5c537236d1) Update libc dep
- See full diff in [compare view](482c7f0643...5c537236d1)
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
**Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.
You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com).
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
</details>
Add linux musl powerpc (32-bit) support
This change adds support for musl on 32-bit powerpc. Most of the general constants in src/unix/notbsd/linux/musl/b32/mod.rs were different from those of the powerpc port, so I moved them over to the individual architecture-specific submodules. The same with the ipc_perm structure.
Add ENOATTR for Android
PR based on https://github.com/rust-lang/libc/pull/594
It's defined in Android sysroot so it should work without test workaround (CI should catch it otherwise?).
Re-add aarch64 stuff removed by previous PR
Previous PR #1023 has removed stuff from mod.rs and added it to some submodules, but
missed the aarch64 submodule.
This caused a build failure for rust on aarch64, see https://github.com/rust-lang/rust/pull/51864.
This copies the stuff that that commit added to the x86_64.rs submodule
and puts it into aarch64.rs.
It's been tested in the rust-lang/rust PR above: https://travis-ci.org/rust-lang/rust/builds/398750336
Previous commit
dcff154781
"libc: changes to ppc64le musl branch to support building of rust on Alpine"
has removed stuff from mod.rs and added it to some submodules, but
missed the aarch64 submodule.
This copies the stuff that that commit added to the x86_64.rs submodule
and puts it into aarch64.rs.
illumos header translation is wrong 02000000 should be 0x80000
I am recently getting into rust and discovered that tokio wasn't working on illumos. I traced it back to mio but ultimately the issue ended up being this value in the libc crate. It looks like the octal value isn't properly translated to the rust crate as hex. Here's a test program I was using on linux and illumos:
```rust
extern crate libc;
#[allow(dead_code)]
const ILLUMOS_EPOLL_CLOEXEC: i32 = 0x80000;
fn find_func() -> usize {
unsafe { libc::dlsym(libc::RTLD_DEFAULT, "epoll_create1\0".as_ptr() as *const _) as usize }
}
fn main() {
let addr = find_func();
#[allow(unused_variables)]
let hex = format!("{:x}", addr);
// I think the position changes per run on linux due to something like ASLR
// so we only test on solaris for this use case
#[cfg(target_os = "solaris")]
assert_eq!(hex, "ffffbf7fff226fe0"); // confirmed with addrtosymstr
unsafe {
let f = std::mem::transmute::<usize, fn(i32) -> i32>(addr);
#[cfg(target_os = "linux")]
let epfd = f(libc::EPOLL_CLOEXEC);
#[cfg(target_os = "solaris")]
let epfd = f(ILLUMOS_EPOLL_CLOEXEC);
println!("call to epoll_create1 returned: {}", epfd);
}
}
```
Which outputs the following:
```
# cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.04s
Running `target/debug/dlsym`
call to epoll_create1 returned: 3
```
Edit: typo
Simplify the stdbuild section
Found this when encountering the code in the rustc submodule and changing the allow for the warnings to deny.
* `no_std` is stable so it does not have to be listed in the `feature` attribute
* `no_std` as an attribute for the crate is already implied by the `#![cfg_attr(not(feature = "use_std"), no_std)]` below
* `staged_api` as an attribute gives a warning. That also matches my knowledge.
libc: changes to ppc64le musl branch to support building of rust on A…
…lpine
This PR includes changes to the libc musl branch to include the correct defines & declarations to support powerpc64. Values that needed changes to a definition for powerpc64.rs that existed higher in the branch also resulted in a change that moved the definition down to the b32/mod.rs, b64/x86_64.rs to ensure that builds continued to work on those architectures.
Verification was done building rust for both ppc64le and x86_64 on Alpine as described in the git project
https://github.com/mksully22/ppc64le_alpine_rust_1.26.2
add fdopendir on macOS
Fixes#1017
I moved it up to src/unix/mod.rs, as it's specified in POSIX.1-2008 and
appears to be implemented on every Unix-like system.
The symbol names on macOS appear similar to those for opendir; I found
them via the commands below. I tested the x86_64 version;
fdopendir$INODE64 worked as expected.
$ nm -arch x86_64 /usr/lib/system/libsystem_c.dylib | grep fdopendir
000000000007ea6d T _fdopendir
000000000002ba97 T _fdopendir$INODE64
$ nm -arch i386 /usr/lib/system/libsystem_c.dylib | grep fdopendir
00082d1e T _fdopendir
0002b528 T _fdopendir$INODE64$UNIX2003
00082d1e T _fdopendir$UNIX2003
Fixes#1017
I moved it up to src/unix/mod.rs, as it's specified in POSIX.1-2008 and
appears to be implemented on every Unix-like system.
The symbol names on macOS appear similar to those for opendir; I found
them via the commands below. I tested the x86_64 version;
fdopendir$INODE64 worked as expected.
$ nm -arch x86_64 /usr/lib/system/libsystem_c.dylib | grep fdopendir
000000000007ea6d T _fdopendir
000000000002ba97 T _fdopendir$INODE64
$ nm -arch i386 /usr/lib/system/libsystem_c.dylib | grep fdopendir
00082d1e T _fdopendir
0002b528 T _fdopendir$INODE64$UNIX2003
00082d1e T _fdopendir$UNIX2003
