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
