OpenBSD port status and tracking

Related Projects
1

This post is intended to be some supplemental documentation for getting Swift and its components running on OpenBSD and describe context on the state of the port. This is done here on the forums in order to more dynamically and rapidly augment "more official" in-tree documentation, which requires pull requests and reviews to update.

Getting the compiler and stdlib built

  • Follow the in-tree documentation (docs/OpenBSD.md).
    • Take special care to the symlinks section -- don't just blindly copy and paste these, because you need to make sure these apply to the current OpenBSD version.
    • This is because LLVM doesn't recognize the OpenBSD platform version scheme, and mix up static and dynamic libraries. There is a manual change that can be made to LLVM that alleviates the need for making changes to the base system, which I will link in a future edit, but probably will not be upstreamed because of comments about OpenBSD potentially adopting adding symlinks anyway.
  • Known issues/deficiencies:
    • The REPL doesn't work (i.e., calling swift without arguments) and will give a scary backtrace, however the "inbuilt JIT" mode does (swift foo.swift).
      • AIUI, this needs more comprehensive lldb work on the platform. This is unlikely to happen any time soon.
  • Necessary cherrypicks:
    • As of 2022-03-10, the Swift compiler should build at HEAD.

Foundation and Dispatch

  • Necessary cherrypicks:
    • As of 2022-02-10, you will need to cherrypick pr #559 in Dispatch and #3004 in Foundation.
  • The Foundation pr is primarily to get CFRunLoop implemented
    • Among other things, this pr uses kevent, which the BSDs all implement. So does xnu, for that matter. It would be a fun experiment to cross-check whether the kevent implementation in that pr works on Darwin...
  • The Dispatch pr implements a few gaps in functionality
    • Specifically, it uses pipe2 and packed file descriptors for runloop implementation, which has inherent tradeoffs for portability.
    • This implementation may still require some additional testing but generally works well and the associated runloop Foundation tests pass. The caveat here, however, is that the Foundation and Dispatch testing coverage may not be as thorough.
    • You will notice that existing in-tree documentation carefully counsels disabling Dispatch in the Swift compiler/stdlib. This is because the Dispatch pr has not landed.
    • If you go the route of cherrypicking these prs, you can go back and compile with Dispatch enabled.

The road to SwiftPM

  • llbuild requires some manual changes to the in-tree support library, but they are minimal.
    • More TK.
  • swift-crypto works well enough if you make the obvious changes such as changing all the defined(__linux__) to defined(__linux__) || defined(__OpenBSD__). However, I don't know if this is advisable to upstream: OpenBSD has libressl and may be somewhat opinionated about security primitives, but an explicit goal of swift-crypto is to be bit-compatible across platforms and therefore may require specific implementations. More thinking and research may be required here.
  • yams needs the usual amd64 naming change and substituting of complex macro DBL_DECIMAL_DIG. Not difficult, just have not done this yet.
  • With these changes SPM seems to build OK.
    • This is no guarantee that other packages that use SPM will build OK, however!

Additional context

  • TK.
13 Likes
2

(Editorial nit) Would you mind turning those references to pending PRs in to links? Makes it easier for people to follow along.

Thanks, and nice work maintaining this port!

3

Done! More braindumping will follow as I get time.

4 Likes
4

Thank you! FreeBSD user hope have it.

1 Like
5

Just so I understand, how much more needs to be done for OpenBSD to be a first class platform on which one could use Swift? I am a FreeBSD user, and I hope to be able to deploy my Vapor sites there, as well as building my Publish there.

I hope that your OpenBSD work will help in that direction. :-)

1 Like
6

"first-class platform" isn't something that is well-defined right now. What level of support are you expecting? I have no idea if Vapor will work, and especially won't work if it depends on Swift packages like swift-nio or what have you -- more portability work needs to be done there.

Regardless, the Swift compiler should build cleanly out of the box. I need to update the docs a little, but essentially, check out cmark, llvm-project, swift, swift-syntax, and run build-script with --bootstrapping=off. Dispatch and corelibs should also build cleanly when picking Dispatch pr #559 as per above.

1 Like
7

My definition of a First-class Platform is one on which all the server-side swift code should run - essentially one with support approximately as good as Linux. I think that means it needs to support Swift Package Manager, all the *NIO libraries, Foundation, and any library I personally use. (Just kidding about the last.)

Again, my real interest is in support for FreeBSD, but I prefer OpenBSD to Linux, so that would be a step in the right direction. :slight_smile:

Thanks for all your hard work!

1 Like