Re-export core::ffi::c_void if it exists
This is the second part of the implementation of [RFC 2521](https://github.com/rust-lang/rfcs/pull/2521), replacing the definition of `c_void` in libc with a re-export of the type from `core::ffi::c_void` on builds it exists for.
This uses the re-export for rustc version `1.31.0` or greater, as `1.30.x` was the current nightly when [the PR for the changes to libcore and libstd](https://github.com/rust-lang/rust/pull/53910) was merged, so I'm assuming the first nightly they will appear in will be `1.31.0`; is this acceptable?
cc rust-lang/rust#53856
Theoretically test statics
There are none of them in `libc` except for `__progname` on Android, but
that one cannot be tested because it's not present in any header files.
Add new FreeBSD socket option SO_REUSEPORT_LB.
FreeBSD 12, which is scheduled to be released soon, has a new socket option SO_REUSEPORT_LB.
From setsockopt man page:
SO_REUSEPORT_LB allows completely duplicate bindings by multiple
processes if they all set SO_REUSEPORT_LB before binding the port.
Incoming TCP and UDP connections are distributed among the sharing
processes based on a hash function of local port number, foreign IP
address and port number. A maximum of 256 processes can share one socket.
Fix mips-unknown-linux-uclibc target
The mips(el)-unknown-linux-uclibc target has apparently been broken in one way or another for over a year. This PR is the patch it took to successfully build a beta toolchain that could support it.
I am pretty sure these fixes are the right answer, after considerable digging in both the libc crate source (_pub-use pub-use everywhere, and not a hint to link_) and the uClibc source (_it's not POSIX, but they've shipped it since 2007, so close enough_).
For those who don't know, the *-uClibc targets are the only way (AFAIK) to create Rust binaries which run on Linux kernels prior to 2.6. It is a use case that is getting quite rare these days, but is still present in embedded ecosystems where chip vendors never migrated their hardware support to newer kernel versions.
Here's hoping these Rust toolchain targets find a maintainer someday.
cc rust-lang/rust#43503
Add TIOCGWINSZ accessor to solaris module
Signed-off-by: Ian Henry <ihenry@chef.io>
I recently noticed downstream that these request values were unavailable and needed for things like [the pb crate](https://github.com/a8m/pb). To get access to the request value I ran the following simple C code:
```
#include <sys/ioctl.h>
#include <stdio.h>
#include <sys/termios.h>
int main(int argc, char **argv) {
printf("Code: 0x%04lx\n", TIOCGWINSZ);
printf("Code: 0x%04lx\n", TIOCSWINSZ);
return 0;
}
```
To then validate the change I ran the following simple rust:
```
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
The futimes(), lutimes(), mq_timedreceive(), and mq_timedsend()
functions were linking against legacy library symbols that need 32-bit
time_t in structures, resulting in an ABI mismatch with 64-bit time_t.
Add libc definitions for Megaton-Hammer, a Switch Homebrew toolchain
I'm working on a pure-rust toolchain to write homebrew for the Nintendo Switch called [Megaton-Hammer](http://github.com/megatonhammer/megaton-hammer). I'm hoping to get those definitions upstreamed to simplify my life :).
This toolchain does not depend on a C compiler or a libc (it reimplements everything in rust) - but given many crates in the Rust ecosystem rely on the libc crate for the definition of various common types, this is what I came up with.
I was wondering what a good target triple would be ? I currently gate the implementation behind `target_os = "switch"`, but if this goes upstream I figure that might cause trouble for people using the Nintendo SDK (they might already be using `target_os = "switch"` for some things). Would it be better to go with `target_env = "megatonhammer"`?
Bump version to 0.2.43
Would be nice to have the new align feature from #1044 available for general use. But mostly I want this released since I have problems using the align feature for a PR on libstd, and I suspect it's somehow because I try to use an unpublished libc (https://github.com/rust-lang/rust/pull/52872).
