Revert the solaris target renaming for semver check
The semver check uses an old nightly and it doesn't have the renamed target yet, I completely forgot it.
r? `@ghost`
Replace `x86_64-sun-solaris` with `x86_64-pc-solaris`
Address the changes by https://github.com/rust-lang/rust/pull/82216. I didn't add `x86_64-sun-solaris` as it's now deprecated.
r? `@ghost`
Remove CI support for `x86_64-rumprun-netbsd`
That target has been removed by https://github.com/rust-lang/rust/pull/82594.
This is intended to unblock CI and we could drop the actual library support for it like CloudABI.
r? `@ghost`
add definitions for s390x musl targets
Add support for s390x musl targets to libc.
I haven't added CI because I am not familiar with the pipelines, but would be glad to do so if somebody outlines what needs to be done.
use GNU/Linux siginfo_t on Android
Bionic uses an unchanged siginfo.h from the upstream linux so why not? :)
I literally just copied everything with siginfo_t from unix/linux_like/linux/gnu/mod.rs to unix/linux_like/android/mod.rs
Implement accept4 on x86 android with `socketcall` syscall.
Linux x86 kernels before 4.3 only support the `socketcall` syscall rather than individual syscalls for socket operations. Since `libc` does a raw syscall for `accept4` on Android, it doesn't work on x86 systems.
This PR instead implements `accept4` for x86 android using `socketcall`. The value for `SYS_ACCEPT4` (in contrast to `SYS_accept4` 👀) is taken from the `linux/net.h` header.
Also note that the `socketcall` syscall takes all arguments as array of long ints. I've double checked with `glibc` to check how they pass arguments, since the Linux man page only says this: "args points to a block containing the actual arguments" and "only standard library implementors and kernel hackers need to know about socketcall()".
This should fix https://github.com/rust-lang/rust/issues/82400
Linux x86 kernels before 4.3 only support the `socketcall` syscall rather than individual syscalls for socket operations. Since `libc` does a raw syscall for `accept4` on Android, it doesn't work on x86 systems.
This PR instead implements `accept4` for x86 android using `socketcall`. The value for `SYS_ACCEPT4` (in contrast to `SYS_accept4` 👀) is taken from the `linux/net.h` header.
Also note that the `socketcall` syscall takes all arguments as array of long ints. I've double checked with `glibc` to check how they pass arguments, since the Linux man page only says this: "args points to a block containing the actual arguments" and "only standard library implementors and kernel hackers need to know about socketcall()".
This should fix https://github.com/rust-lang/rust/issues/82400
Fix mips64-musl ioctl consts to c_int
This arch was overlooked or unspecified in earlier PRs that fixed
c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301,
or PR #1097 for such prior art, however these are still args to
fn ioctl on mips64-musl, which is expecting c_ints.
Some numbers acquired casts to reflect the fact the data is being
used and (so should be written as) an unsized bitfield, even if
the value is greater than i32::MAX.
Currently rustc is not building on mips64-linux-musl because of this error.
This arch was overlooked or unspecified in earlier PRs that fixed
c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301,
or PR #1097 for such prior art, however these are still args to
fn ioctl on mips64-musl, which is expecting c_ints.
Some numbers acquired casts to reflect the fact the data is being
used and (so should be written as) an unsized bitfield, even if
the value is greater than i32::MAX.
WASI: define `AT_FDCWD` and update to latest WASI libc
Update to the latest WASI libc, define `AT_FDCWD`, update the signature
for __wasilibc_find_relpath, and add declarations for various
`__wasilibc_` utility functions.
Update to the latest WASI libc, define `AT_FDCWD`, update the signature
for __wasilibc_find_relpath, and add declarations for various
`__wasilibc_` utility functions.
Haiku: use raw pointers instead of references in convenience functions
The Haiku API has some convenience macros to make it easier to call certain
functions. In the libc implementation, these are implemented as unsafe
functions. The previous choice was to take certain pointer parameters as
references, and do the conversion to raw pointers when the actual external
function was called.
However, this causes issues with the image_info struct, which needs to be
initialized in Rust, before a native API call is used to enter data. Since
part of this structure consists of function pointers, mem::zeroed() cannot be
used, since in Rust function pointers cannot be NULL. Thus one needs to use the
MaybeUnit<T> API to properly initialize it. This then makes it problematic to
use the convenience functions, as a MaybeUnit<image_info> cannot be converted
into an &mut image_info before it is marked as initialized with valid data. It can
be converted into a raw *mut image_info, so if the function accepts this as a
parameter it can be used.
For consistency, all convenience functions have been converted from using
references to using raw pointers.
Move uclibc under linux
This is a first cut at moving uclibc under linux, alongside `musl` and `gnu`.
All tests pass on a vexpress a9 running in qemu. I am working on testing the other tier 3 uclibc targets: `mips-unknown-linux-uclibc` and `mipsel-unknown-linux-uclibc`. ~Not having access to these platforms, I am working on getting them running in qemu, but it may take a bit.~
The style check doesn't pass. I would appreciate some direction here. Many of these constants are defined under 2-of-3 out of musl/glibc/uclibc, so I'm not sure whether I should transform:
```rust
#[cfg(not(target_env = "uclibc"))]
pub fn foo();
```
into 2 separate declarations, one each in `musl/mod.rs` and `gnu/mod.rs` or use a `cfg_if` block for each one (which explodes 2 lines into 5).
- [x] Help me choose which fix to use for the items defined in musl and gnu but not uclibc.
It's my guess that exploding into the `cfg_if` block is better for long-term maintainability, but I'd really appreciate opinions from the maintainers.