Fix _CMSG_ALIGN on DragonFly

[rtzoeller]

Based on the following DragonFly source:

• https://github.com/DragonFlyBSD/DragonFlyBSD/blob/f6a040333742c20fd088944a507721fda481fe08/sys/sys/socket.h#L480
• https://github.com/DragonFlyBSD/DragonFlyBSD/blob/f6a040333742c20fd088944a507721fda481fe08/sys/cpu/x86_64/include/alignbytes.h#L35

This fixes nix's failing scm tests on DragonFly.

[rust-highfive]

r? @Amanieu

(rust-highfive has picked a reviewer for you, use r? to override)

[asomers]

Note that this is not a libc bug. Rather, it's an ABI change in Dragonfly. libc's code was correct at the time it was written. Presumably this PR will break Nix's SCM tests for older Dragonfly versions. I don't see any CHANGELOG file for libc. Is there a different way to announce a change of the minimum supported OS version ?

DragonFlyBSD/DragonFlyBSD@b3aa44a

[rtzoeller]

Is there a different way to announce a change of the minimum supported OS version ?

In the past I've been told to mark items impacted by ABI changes as deprecated, and then waiting a few libc releases before submitting the change. In theory this notifies everyone uptaking new libc versions at a periodic cadence.

My reluctance to do so here is motivated by my experience doing so for a previous DragonFly ABI change:

• We needed to adjust the build process for the nix crate twice in order to accommodate the change due to the deprecation warnings being converted to errors. Given the small DragonFly user-base and its tier 3 status, IMHO handling this deprecation was disproportionately painful to the actual impact of the change.
• DragonFlyBSD/DragonFlyBSD@b3aa44a was submitted two years and multiple DragonFly releases ago, first appearing in DragonFly 5.8. I don't believe any versions of DragonFly older than that are still supported by the DragonFly team.
• libc does not list a supported version for DragonFly, and the current state of libc likely straddles multiple ABI versions making it an imperfect match for any version of DragonFly.
  • Even if libc did claim support for specific versions of DragonFly, how to best support that mechanically is an open question, @asomers as you're aware regarding FreeBSD. :(

IMHO, given current interest/investment levels towards rust on DragonFly, the best strategy is for libc to always target the latest in-development version of DragonFly (perhaps stabilizing briefly around DragonFly release windows). This helps guarantee that each DragonFly release is reasonably supported by at least one version of libc, date-aligned. If needed, users could force other crates to use this version of libc and cherry-pick additional changes on top of it.

I'm not sure there's sufficient interest to maintain support for multiple versions like FreeBSD, and having a "live at head" policy seems more internally consistent than the ABI-version-mystery-meat that exists today. It's certainly imperfect, but I'd wager most people uptaking new versions of rust on DragonFly are also uptaking new versions of DragonFly, and vice-versa.

[asomers]

I agree that #[deprecated] is too much trouble for this case. It's not really appropriate anyway, for APIs that will be changed but not removed, without replacement.

[Amanieu]

I'm not sure there's sufficient interest to maintain support for multiple versions like FreeBSD, and having a "live at head" policy seems more internally consistent than the ABI-version-mystery-meat that exists today. It's certainly imperfect, but I'd wager most people uptaking new versions of rust on DragonFly are also uptaking new versions of DragonFly, and vice-versa.

I'm happy to go with this for now (unless someone comes along and complains).

@bors r+

[bors]

📌 Commit 67464ff has been approved by Amanieu

[bors]

⌛ Testing commit 67464ff with merge f51fd85...

[bors]

☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing f51fd85 to master...