Add preadv and pwritev for macOS
Add declarations for the preadv and pwritev system calls, introduced
in macOS 11.0 (Big Sur).
Signed-off-by: Sergio Lopez <slp@redhat.com>
Fix missing dl lib on armv5te-unknown-linux-uclibceabi
I'm unable to link my executable for the Linux uClibc environment because of some missing symbols from the dl lib:
```
/home/operutka/goodcam/goodcam-server/target/armv5te-unknown-linux-uclibceabi/release/deps/goodcam_server-aefb92c403e8cd55.goodcam_server.dzc3futp-cgu.0.rcgu.o: In function `mio::sys::unix::dlsym::fetch::he5e2964820cfd29d':
goodcam_server.dzc3futp-cgu.0:(.text._ZN3mio3sys4unix5dlsym5fetch17he5e2964820cfd29dE+0x30): undefined reference to `dlsym'
/home/operutka/goodcam/goodcam-server/target/armv5te-unknown-linux-uclibceabi/release/deps/goodcam_server-aefb92c403e8cd55.goodcam_server.dzc3futp-cgu.0.rcgu.o: In function `std::sys::unix::weak::fetch::h5ed4b0fa5792ef5c':
goodcam_server.dzc3futp-cgu.0:(.text._ZN3std3sys4unix4weak5fetch17h5ed4b0fa5792ef5cE+0x3c): undefined reference to `dlsym'
```
The libc crate is being used at both of these points.
This change fixes the issue for me. I've tested it with two different GCC cross toolchains for armv5te and it seems to be OK.
_Note: I'm building my own std using the unstable build-std Cargo feature._
Fix error when building rustc with a custom libc
When pulling a custom `libc` into a `rustc` build (with the `rustc-dep-of-std` feature set), the following error occurs:
```
error: unused attribute
--> /hdd/libc/src/lib.rs:29:1
|
29 | #![no_std]
| ^^^^^^^^^^
|
= note: `-D unused-attributes` implied by `-D warnings`
error: crate-level attribute should be in the root module
--> /hdd/libc/src/lib.rs:29:1
|
29 | #![no_std]
| ^^^^^^^^^^
```
I think this is because both the `no_std` and `no_core` attributes are specified, although the error message doesn't make this very clear. This PR changes this so `no_std` is only supplied when the `rustc-dep-of-std` feature is not.
Add definitions from `linux/can.h`, which is a "base" header for remainder
of SocketCAN functionality.
Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
Make test suite pass on macOS on aarch64
While working on #2007 I tried to run `cargo test` in `libc-test`, which failed, because the definition of `__darwin_mcontext64` was incomplete (see #1990). This adds definitions for the exception state and the floating point state as well.
`libc-test` still does not pass, because I use the type `[u128; 32]` for the `__v` field of `__darwin_arm_neon_state64` (in C it is `__uint128_t __v[32]`. `ctest2` does not translate `u128` to `__uint128_t` and the generated C code does not compile. Any ideas for working around this?
On FreeBSD, the aio_ functions require librt _only_ if they use
SIGEV_THREAD completion notification. However, due to Rust's originally
poor support for C unions, libc doesn't even expose some of the fields of
struct sigevent that SIGEV_THREAD requires. Accordingly, there is no
need to link librt to programs using aio via libc.
This change partially reverts 8c23f77704
from PR #1630 .
While I'm here, fix the linkage of lio_listio on DragonflyBSD. It
_does_ require librt.
Adds the ip_mreqn struct for the Fuchsia platform, as defined by ip(7).
Enables joining an IPv4 multicast group by NIC ID rather than by its
assigned IPv4 address.
Declare statfs MAGIC constants as c_uint on s390x
Hi, I work in container development on Linux on Z at IBM.
On s390x (IBM Z) in GNU/Linux, a statfs `f_type` is 4 bytes wide, contrary to 8 bytes on most architectures.
This is already implemented in libc:
```sh
$ grep -r f_type src/unix/linux_like/linux/gnu/b64 | uniq
src/unix/linux_like/linux/gnu/b64/sparc64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/powerpc64/mod.rs: pub f_type: ::__fsword_t,
src/unix/linux_like/linux/gnu/b64/riscv64/mod.rs: pub f_type: ::c_long,
src/unix/linux_like/linux/gnu/b64/mips64/mod.rs: pub f_type: ::c_long,
src/unix/linux_like/linux/gnu/b64/s390x.rs: pub f_type: ::c_uint, # s390x is uint
src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs: pub f_type: ::__fsword_t,
```
However, the `*_MAGIC` constants (such as `EXT4_SUPER_MAGIC`) in `src/unix/linux_like/linux/gnu/mod.rs` are defined as `c_long`, when they should be `c_uint` on s390x.
This ends up biting me [here](https://github.com/kata-containers/cgroups-rs/blob/master/src/hierarchies.rs#L231).
Thus, I suggest the attached change to only define these constants for architectures other than s390x and instead define them as uint for s390x.
This is safe since none of the constants are any wider than 32bit.
Please let me know if you think this could be done more elegantly.
Previously, statfs MAGIC constants like EXT4_SUPER_MAGIC were defined as c_long
for linux-gnu, whereas a statfs f_type is a c_uint on s390x. This commit
exempts these definitions from s390x and instead defines these constants as
c_uint on s390x. This is safe as none of these constants are wider than 32bit.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
Make si_status method more compatible
Now that [this PR](https://github.com/rust-lang/libc/pull/1858/files) has been merged, `siginfo_t::si_status` is a method for some targets and a field on others. This PR adds the method on targets that already expose the field, which lets the method be used without target detection.
I think this change is backward compatible, but it would be better if someone else could confirm that. The struct would now have a method and a field with the same name on some targets. If that's incompatible, another method could be added that accesses the field or calls the method depending on the target, but this is cleaner.
Android: make statfs64.f_fsid public
This has been the case since the initial commit
a36da11fb9. But there is no reason to hide
this struct member specifically.
The visibility has been not public since the initial commit[1]. But there
is no reason to hide this struct member specifically.
The type has also been "__fsid_t" in Android's bionic[2], so fix that as
well. This makes it consistent with statfs.f_fsid nicely.
[1] a36da11fb9
[2] https://cs.android.com/search?q=file:bionic%2Flibc%20f_fsid
Add getrandom to FreeBSD
Introduced in FreeBSD 12.0.
Manual page: https://www.freebsd.org/cgi/man.cgi?query=getrandom.
Not sure if the constants should be `c_int`, just matching the `flags` argument in the function, in c they're macros.
add `getnameinfo` && `EAI_NODATA` in uclibc
when compiling `dns-lookup v1.0.5` in target `mipsel-unknown-linux-uclibc`
```shell
error[E0432]: unresolved import `libc::getnameinfo`
error[E0531]: cannot find unit struct, unit variant or constant `EAI_NODATA` in crate `c`
```
This avoids relying on Android 5.0 / API level 21. The Linux kernel used
by Android supports the syscall (except in truly ancient Android
versions), but the Android libc did not expose a wrapper.
Adding dl_iterate_phdr function and related structs and types to the
uclibc module as per the file include/link.h found in the uClibc-ng
repository as of version 1.0.36. This is necessary in order for rust to
work with a new target armv7-unknown-linux-uclibceabihf.
We leave IPPROTO_MAX as is for the time being. However, in recent
kernel releases IPPROTO_MAX is actually higher and reflects the
addition of IPPROTO_MPTCP.
Include sendfile64() for Linux
`sendfile` uses the `off_t` type, which is platform dependent. On 64-bit architectures, I can pass an `off64_t` as the third argument to `libc::sendfile`, but on 32-bit architectures, this does not compile. `sendfile64` on the other hand uses a 64-bit wide offset even on 32-bit architectures, so that `off64_t` can be used.
Excerpt from `man 2 sendfile`:
> The original Linux sendfile() system call was not designed to handle large file offsets. Consequently, Linux 2.4 added sendfile64(), with a wider type for the offset argument.
I hope that supporting Linux versions below 2.4 is not a requirement for libc.
From sys/uio.h. Note that preadv64/pwritev64 are already included in
src/unix/linux_like/mod.rs.
Also fix parameter names of process_vm_[readv,writev] to match Bionic
header.
Add deprecation notice to `af_alg_iv::as_slice` and trait implementations that depend on it
These trait implementations exposed an unsound API (see https://github.com/rust-lang/libc/issues/1501).
Support was previously added to gnu x86_64 and all musl targets but
others were not included because of a roundtrip issue [1].
This commit adds support for the ip_mreqn struct on all Linux GNU
targets which did not have the roundtrip issue.
[1]: https://github.com/rust-lang/libc/issues/1558
Signed-off-by: Bartel Sielski <bartel.sielski@gmail.com>
Move the link line for `libdl` up to `src/unix/mod.rs`, making it easier
to see all the libraries `libc` links to.
This also makes `libdl` respect `target-feature=+crt-static`.
The two library blocks that specify `#[link(name = "util")]` do not
actually reference any functions in `libutil`; the functions that do use
`libutil` don't have any reference to it. And having two library blocks
specify it results in two separate inclusions of `-lutil` on the linker
command line. Move the link lines up to `src/unix/mod.rs`, making it
easier to see all the libraries `libc` links to.
This also makes `libutil` respect `target-feature=+crt-static`.
This will need corresponding changes in rust-lang/rust to activate, but
this will make it possible to make those changes.
Note that despite the apparent redundancy in config directives, the link
directives cannot be simplified any further. Attempting to factor out
the checks for `target_feature = "crt-static"` does not work.
These syscalls were added recently, and therefore have consistent
numbers across different architetures (other than the weird offsetting
on some platforms).
The pr #1870 introduced safe_f! macro, which made some functions like
WIFEXITED and WEXITSTATUS const and safe on linux_like platform only,
which causes inconsistency when trying to use those functions in crates
compiled across multiple platforms, as using unsafe on those functions
will generate unused_unsafe warning on linux platforms and lack of
unsafe block will fail compilation on non-linux platforms.
To avoid the inconsistency, this commit applies the same macro for all
the same functions on other platforms too.
These constant can be used to determine the maximum number of iovecs can
be passed to functions like readv/writev.
Linux like uses UIO_MAXIOV, while the BSD family uses IOV_MAX.
Expose __errno_location() (introduced in DragonFlyBSD 5.8), which
returns the current thread's errno value. This is similar to Linux
and avoids having a separate module that defines both errno (which
depends on the thread_local feature) and an __error() function.
bors
Patrick Mooney
Sergio Lopez
Amanieu d'Antras
Sébastien Marie
Tamir Duberstein
Isaac Woods
Yuki Okushi
Damian Jarek
Josh Triplett
Benedikt Steinbusch
kolapapa
Alan Somers
Thomas de Zeeuw
dylni
Sam Balana
Jakob Naucke
Luca Barbato
Ondrej Perutka
whitequark
kolapapa
Victor Hsieh
Jack Lloyd
David Craven
Joshua M. Clulow
zonyitoo
Kenta Tada
Maarten de Vries
Tudor Sidea
Jason King
Noah
0e4ef622
Lzu Tao
George Hopkins
brian-cook
Fredrik Fornwall
Fabian Muscariello
Andrew Walbran
DarcInc
Eduardo Sánchez Muñoz
rupansh-arch
Max Blachman
Robert Collins
Daniel Brooks
Alistair Francis
John Paul Adrian Glaubitz
Bartel Sielski
Aaron Hill
Matt Schulte
Dan Gohman
Daniil Bondarev
LinkTed
Petr Sumbera
MeiK
alindima
John Colanduoni
Chuck Musser