Rename the dox configuration option to cross_platform_docs
The libc crate is used as a dependency of the Rust compiler. Its build system passes `--cfg dox` to all crates when generating their documentation. libc's documentation is generated when the build system is asked to generate the compiler documentation because `cargo doc` automatically documents all dependencies.
When the dox configuration option is enabled, libc disables its dependency on the core crate and provides the necessary definitions itself. The dox configuration option is meant for generating documentation for a multitude of targets even if the core crate for that target is not installed. However, when documenting the compiler, it's not necessary to do that; we can just use `core` or `std` as usual.
This change is motivated by the changes made to the compiler in rust-lang/rust#48171. With these changes, it's necessary to provide implementations of the `Clone` and `Copy` traits for some primitive types in the library that defines these traits (previously, these implementations were provided by the compiler). Normally, these traits (and thus the implementations) are provided by core, so any crate that uses `#![no_core]` must now provide its own copy of the implementations.
Because libc doesn't provide its own copy of the implementations yet, and because the compiler's build system passes `--cfg dox` to libc, generating the documentation for the compiler fails when generating documentation for libc. By renaming the configuration option, libc will use `core` or `std` and will thus have the necessary definitions for the documentation to be generated successfully.
**Note:** rust-lang/rust#48171 is blocked on this PR and on a release of libc including this change on crates.io. (Some crates in the compiler use libc as a submodule, while others use a version from crates.io.)
The libc crate is used as a dependency of the Rust compiler. Its build
system passes `--cfg dox` to all crates when generating their
documentation. libc's documentation is generated when the build system
is asked to generate the compiler documentation because `cargo doc`
automatically documents all dependencies.
When the dox configuration option is enabled, libc disables its
dependency on the core crate and provides the necessary definitions
itself. The dox configuration option is meant for generating
documentation for a multitude of targets even if the core crate for that
target is not installed. However, when documenting the compiler, it's
not necessary to do that; we can just use core or std as usual.
This change is motivated by the changes made to the compiler in
rust-lang/rust#48171. With these changes, it's necessary to provide
implementations of the Clone and Copy traits for some primitive types in
the library that defines these traits (previously, these implementations
were provided by the compiler). Normally, these traits (and thus the
implementations) are provided by core, so any crate that uses
`#![no_core]` must now provide its own copy of the implementations.
Because libc doesn't provide its own copy of the implementations yet,
and because the compiler's build system passes `--cfg dox` to libc,
generating the documentation for the compiler fails when generating
documentation for libc. By renaming the configuration option, libc will
use core or std and will thus have the necessary definitions for the
documentation to be generated successfully.
Update the FreeBSD CI image
As per #948 and #799 the FreeBSD CI qemu image needs to be updated to FreeBSD 11. I have done this and updated the README with the detailed steps taken. The new image is available for download at: http://bsd-ci.com/FreeBSD-11.1-RELEASE-amd64.qcow2.xz
Added ucred (sockpeercred) for OpenBSD and Bitrig
OpenBSD and Bitrig has `struct ucred`implemented in the way it is used in `getsockopt(2)` with `SOL_SOCKET` and `SO_PEERCRED`. However, it is called `struct sockpeercred`.
Source: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/socket.h?rev=1.65&content-type=text/x-cvsweb-markup
I added a type alias for `ucred` to enable Linux compatibility, but I'm not sure this is the correct way to do it.
Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.
This will fix rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in f713b08c02.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.
The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation. On the other hand
Rust won't work at all on 12 without doing this currently. In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.
A better, or complementary, approach would be something like proposed in
https://github.com/rust-lang/rfcs/pull/2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.
The symbol versions used were taken from the old version in
f713b08c02 (diff-61a32fcfb7ecd4517665fed591813c57)
and
f713b08c02 (diff-7f67ccf8b5f44ff2f54eaab0207abb8d).
The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc. Only functions using dirent, stat, glob_t,
and dev_t need the changes.
Fixes https://github.com/rust-lang/rust/issues/42681
This follows the same method as other platforms like OSX and NetBSD.
This will fix rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in f713b08c02.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.
The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation. On the other hand
Rust won't work at all on 12 without doing this currently. In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.
A better, or complementary, approach would be something like proposed in
https://github.com/rust-lang/rfcs/pull/2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.
The symbol versions used were taken from the old version in
f713b08c02 (diff-61a32fcfb7ecd4517665fed591813c57)
and
f713b08c02 (diff-7f67ccf8b5f44ff2f54eaab0207abb8d).
The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc. Only functions using dirent, stat, glob_t,
and dev_t need the changes.
Fixes https://github.com/rust-lang/rust/issues/42681
Link against kevent@FBSD_1.0 to fix ABI compat with FreeBSD12.
struct kevent was modified in FreeBSD12. The @FBSD_1.0 symbol supports the old
structure ABI still.
This allows the `mio` crate tests to now pass on FreeBSD12.
struct kevent was modified in FreeBSD12. The @FBSD_1.0 symbol supports the old
structure ABI still.
This allows the `mio` crate tests to now pass on FreeBSD12.
Add IPV6_UNICAST_HOPS to fuchsia module
Recent change #925 added constants for IPV6 multicast, but seems to have inadvertently left off IPV6_UNICAST_HOPS from the fuchsia module.
Fixes#932
