Test preadv and pwritev on more operating systems

[asomers]

This was an oversight from PR #1511. Also, update the OSX test environment for Big Sur. Big Sur is the first OSX version that supports preadv/pwritev

[asomers]

@rtzoeller do you know what's going on with the Dragonfly build?

[rtzoeller]

@rtzoeller do you know what's going on with the Dragonfly build?

@asomers I think it's related to this commit, but I'm not sure what the actual issue is. I'll look into it.

rust-lang/rust@e68887e

[rtzoeller]

@asomers I think rust-lang/rust@e68887e is just a bad change?

Per sys/socket.h on my system, the cmsgcred members defined in rust-lang/libc are correct, and the ones rustc is attempting to access are incorrect. The error message looks correct.

Will removing DragonFly from bors.toml let us submit this with a failing DragonFly build? That seems like the best short-term solution, since presumably rustc will eventually be fixed and this PR doesn't touch DragonFly in a special way.

---

@devnexen does rust-lang/rust@e68887e compile for you?

[asomers]

Will removing DragonFly from bors.toml let us submit this with a failing DragonFly build? That seems like the best short-term solution, since presumably rustc will eventually be fixed and this PR doesn't touch DragonFly in a special way.

It will, but then we'll be cursed with a nasty "failing build x" on our github page. What about pinning the toolchain to a specific nightly version for the Dragonfly build?

[rtzoeller]

Will removing DragonFly from bors.toml let us submit this with a failing DragonFly build? That seems like the best short-term solution, since presumably rustc will eventually be fixed and this PR doesn't touch DragonFly in a special way.

It will, but then we'll be cursed with a nasty "failing build x" on our github page. What about pinning the toolchain to a specific nightly version for the Dragonfly build?

I like that idea. Shall we try the commit/day prior to rust-lang/rust@e68887e?

[devnexen]

In the meantime will fix the build on rust, thanks for spotting this.

[asomers]

Will removing DragonFly from bors.toml let us submit this with a failing DragonFly build? That seems like the best short-term solution, since presumably rustc will eventually be fixed and this PR doesn't touch DragonFly in a special way.

It will, but then we'll be cursed with a nasty "failing build x" on our github page. What about pinning the toolchain to a specific nightly version for the Dragonfly build?

I like that idea. Shall we try the commit/day prior to rust-lang/rust@e68887e?

Yeah, I'll try it.

[asomers]

@rtzoeller should be good to review now

[rtzoeller]

bors r+

[bors]

Build succeeded:

• Android aarch64
• Android arm
• Android armv7
• Android i686
• Android x86_64
• DragonFly BSD x86_64
• FreeBSD amd64 & i686
• Fuchsia x86_64
• Illumos
• iOS aarch64
• iOS x86_64
• Linux aarch64
• Linux arm gnueabi
• Linux arm-musleabi
• Linux armv7 gnueabihf
• Linux i686
• Linux i686 musl
• Linux MIPS
• Linux MIPS64
• Linux MIPS64 el
• Linux mipsel
• Linux powerpc
• Linux powerpc64
• Linux powerpc64le
• Linux s390x
• Linux x32
• Linux x86_64
• Linux x86_64 musl
• Minver
• NetBSD x86_64
• OpenBSD x86_64
• OSX x86_64
• Redox x86_64
• Rust Stable