OpenBSD port tracking

[3405691582]

Description

Instead of using the forums, use this Github issue to track OpenBSD porting status and notes that are beneficial for other people trying to build Swift on this platform but not necessarily appropriate for putting into prs yet for official documentation.

Notes

Last edit: 2025-01-20.

Currently the project contains a percentage of C++ dependencies. However, Swift will eventually be written with critical components in Swift, requiring us to build a bootstrap toolchain. Therefore, there are three main different types of build output to think about, namely,

0. the legacy compiler toolchain containing just the legacy Swift libraries and compiler (i.o.w., no Dispatch, no Foundation)
1. the bootstrap toolchain containing the legacy compiler toolchain plus the minimal set of dependencies to build the standard toolchain components written in Swift (swift-driver, etc.)
2. the standard toolchain, including components written in Swift

The legacy compiler toolchain is more or less working, but is not broadly useful. The standard toolchain is not completed yet. We need to create a bootstrap toolchain, since there is no prebuilt toolchain for OpenBSD, and we will eventually need one in the future to build Swift after some point.

• To create the legacy compiler toolchain (complete):

  • Prepare repositories (follow the doc, mostly).
    • Use Build without swift host tools #77815.
      • Use a compiler directive #if hasFeature(Macros) in stdlib/public/core/SwiftifyImport.swift as well.
      • At HEAD, Reapply "[SwiftLexicalLookup] New unqualified lookup implementation validation" #78335 will cause a linker error for bootstrap builds that will eventually require some attention. For now, ensure sources are at the revision prior to this change, or patch manually.
    • Use Enable PACBTI on OpenBSD/arm64. #78394, otherwise swiftc will emit binaries that die with SIGILL.
  • Build (follow the doc, mostly).
    • The symlink trick appears no longer necessary; you can skip it.
    • You can turn on SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY and SWIFT_IMPLICIT_CONCURRENCY_IMPORT; but you must turn these on for the bootstrap toolchain.

• To create the bootstrap toolchain (in progress/incomplete):

  • Prepare repositories, as per above.
  • Prepare additional repositories.
    • Clone swift-corelibs-libdispatch, swift-corelibs-foundation, swift-foundation, swift-collections, swift-foundation-icu.
    • Use Support OpenBSD. swift-corelibs-libdispatch#559 for Dispatch.
    • Use Fix OpenBSD clause. swift-corelibs-foundation#5160 for swift-corelibs-foundation.
    • Use OpenBSD support. swift-foundation#1126 for swift-foundation.
  • You will also likely need to turn on SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING, SWIFT_BUILD_REGEX_PARSER_IN_COMPILER and SWIFT_ENABLE_SYNCHRONIZATION if they are not on already.
  • There is an upstream LLVM issue that means that clang as-built from LLVM will crash when generating machine code with stack protection on arm64. This affects swift-corelibs-libdispatch and swift-foundation-icu. Work around it by temporarily disabling stack protection with -fno-stack-protector.
  • Foundation build for FoundationEssentials has error if any output files are specified, they all must be
    • this is due to cmake adding the static library dependencies for _FoundationCShims and _FoundationCollections as files and not library flags.
    • even working around that, the Release compiler crashes (and not just on OpenBSD).
      • Linux doesn't seem to have this problem with 6.0 but does on 6.1. OpenBSD has a similar (same?) problem with 6.0.
      • Debug compiler might actually be working now at HEAD.
  • I think Swift's C++ interop doesn't work with libc++ platforms and needs to be provided for C++ interop to work. (I think this is why there are errors about a missing Clang module for CxxStdlib). Moreover, OpenBSD's C++ includes are missing a modulemap. Workaround with turning SWIFT_ENABLE_EXPERIMENTAL_CXX_INTEROP off, but this is probably going to be required as progress is made.
  • We likely need an implementation for stdlib/public/Synchronization/Mutex.swift, since Foundation seems to have dependencies. Work around with the 5.10 version of swift-corelibs-foundation, which is the one prior to Mutex being adopted.

• To create the standard toolchain (very incomplete):

  • Prepare repositories, as per above.
  • Prepare additional repositories: dependencies for swift-driver.
    • Clone swift-llbuild (as llbuild), swift-tools-support-core, swift-argument-parser and Yams (as yams).
      • llbuild needs the same -Xlinker -Bsymbolic change and temporary -fno-stack-protector change.
      • llbuild and TSC built with cmake includes -lc for some reason linking libllbuildSwift, which gives a duplicate symbol error with atexit at link time. Workaround by clearing CMAKE_C_IMPLICIT_LINK_LIBRARIES and/or CMAKE_CXX_IMPLICIT_LINK_LIBRARIES .

• Needs investigation:

  • swiftc -num-threads can be memory-hungry and cause lockups; check and make sure threading is WAI
  • Even with using the "minimal" bootstrap toolchain (without Foundation) and --skip-early-swift-driver to build the Swift, there are a number of issues with modules that prevent a successful build. Current suspicion is bad libc++ interaction with modules and/or existing upstream bugs with modules.
  • A less drastic workaround for the upstream clang crash is necessary.
  • Check this all works back on amd64 at some point.

[finagolfin]

I've assigned you on this issue.

there are a number of issues with modules that prevent a successful build. Current suspicion is bad libc++ interaction with modules and/or existing upstream bugs with modules.

Have you tried turning off inline bridging mode, as currently done for Windows and as I used to do for Android?

I suggest you apply to be a committer if you plan to work on this port more. I can't say if you will get it, as I don't decide that, but based on your extensive track record, I suspect you will.