Build on OpenBSD

[jakepetroules]

Building on OpenBSD hosts, but not necessarily building for a OpenBSD target on a OpenBSD host.

[jakepetroules]

@3405691582, would you be interested in taking this? I expect the changes will be similar to #12.

[3405691582]

Yes, I can take this for now. Just know I'm currently blocked on trying to bring up swiftpm, so it may be a while before I can properly look at what's needed here.

[3405691582]

@jakepetroules it seems like there's not an easy way to get the toolchain detected properly without installation to the base system (which I don't want to do and shouldn't have to do just yet). That might be a simple feature or change to Sources/SWBGenericUnixPlatform/Plugin.swift. But if I fudge this for now by editing to look for ar instead of swift, I can make some progress.

It seems swift-build wants to use working-directory unconditionally and thus results in an error from llbuild, namely error: unknown working-directory unsupported on this platform. We probably need to just omit this flag on OpenBSD because llbuild wants to use some posix_spawn nonportable features. Does that sound reasonable?

[jakepetroules]

@3405691582 I think what we need to do is implement a fork/exec fallback in llbuild when posix_spawn_file_actions_addchdir is unavailable. We need it for Amazon Linux 2 as well, which uses an old Glibc.

That said, OpenBSD is one of the only platforms where posix_spawn_file_actions_addchdir is not available, and that is a new function that's specified as part of the POSIX 2024 standard. Do you have influence in the OpenBSD community and is that something you could help push on getting added?

[3405691582]

I'll investigate that option.

Do you have influence in the OpenBSD community and is that something you could help push on getting added?

I don't. I could also look into this, but it would be something low on the list of relative priorities.

[jakepetroules]

It would be nice for OpenBSD to come into POSIX compliance and add posix_spawn_file_actions_addchdir, but FWIW Swift Subprocess is switching to use fork/exec everywhere but Darwin (and we'll adopt it soon), and I added a fallback for the llbuild path in swiftlang/swift-llbuild#981, so we aren't blocked on this issue anymore.