Define mkostemp(s) and <spawn.h> bindings on DragonFly

[jrmarino]

Description

This changeset defines bindings for mkostemp, mkostemps, and the <spawn.h> functions on DragonFly.
These are required to build fish 4.0.0 (https://github.com/fish-shell/fish-shell)

Sources

<spawn.h>
<stdlib.h>

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

The signatures look correct to me, but a lot of these are defined in freebsdlike/freebsd/mod.rs. Instead of adding new definitions, could you move these existing functions up to freebsdlike/mod.rs so they are shared between Dragonfly and FreeBSD? As long as they share the same signature.

<spawn.h>
<stdlib.h>

Are permalinks to Dragonfly's libc headers available anywhere?

Cc @asomers for the FreeBSD family, I'm not sure if we have a dedicated person for Dragonfly.

[jrmarino]

actually all the changes are shared with FreeBSD.
Why is there a notice that the branch has conflicts? I just created it from the head today.

So I didn't realize the "mod.rs" in the parent directory was "shared" between FreeBSD and DragonFly. I was attempted to fix DragonFly without touching FreeBSD.

However, I can certainly relocate the definitions from Freebsd/mod.rs to the parent mod.rs, and drop the changes to dragonfly/mod.rs, if that's what is desired.

[tgross35]

However, I can certainly relocate the definitions from Freebsd/mod.rs to the parent mod.rs, and drop the changes to dragonfly/mod.rs, if that's what is desired.

That would be preferable if they work for both, we try to keep definitions deduplicated where possible.

Why is there a notice that the branch has conflicts? I just created it from the head today.

#4290 merged a few hours ago which added a function at the end of the same block, not much of a conflict but it can't merge automatically.

[jrmarino]

I'm probably going to make another branch, push another PR, and close this one with a reference.
I don't know if merges are flat or not, but it would be a bit cleaner if you don't.

[jrmarino]

replacement PR: #4294
Closing this one.

[tgross35]

I don't know if merges are flat or not, but it would be a bit cleaner if you don't.

They are as-is with a merge commit (GH doesn't allow much configuration with merge queues), I ask the author to squash/clean up history if needed. Atomic commits are fine as long as it builds between (since I do a lot of cherry picks).