-
Notifications
You must be signed in to change notification settings - Fork 10.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenBSD port tracking #78437
Comments
I've assigned you on this issue.
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. |
Note that yams has been removed in trunk, #78826. |
I've experienced trouble with both PURE and INLINE bridging modes. Thankfully by turning interop off for now this sidesteps the issue and haven't been forced to deal with this problem further yet, though I likely will eventually. |
OK, pure bridging also stopped working for me natively on Android last March in trunk, but worked for building 5.10. You may want to try it with 5.10 on OpenBSD and see if that works. At the very least, that could give you a working "standard toolchain" that you could use to bootstrap everything else.
Yes, you will need it, as more and more of the compiler is written in Swift and directly calls LLVM/Swift C++ APIs inside the compiler.
It does work, as most Swift platforms currently use libc++, such as all Darwin platforms and Android. Egor even got it working on linux, #75589. That said, it can be a bit flaky and required some small changes to work on Android.
That module is added in this repo, you may just need to enable OpenBSD there, as Alex did for Android.
That's surprising, as libc++ has shipped with a module map for years now. If OpenBSD is not including it for some reason, try copying it over and using it. |
I have what I think is a janky standard toolchain already atop HEAD/6.2 with C++ interop turned off, but granted, the next step is testing it to make sure it actually properly incorporates the Swift compiler sources. These are good breadcrumbs for when I get back to trying to reenable interop, thanks! |
@3405691582, thanks for your work on the OpenBSD port! We've recently open sourced Xcode's build system engine (Swift Build) which will eventually become part of the toolchain. I'm currently working on adding FreeBSD support there, and I expect OpenBSD support would be a similar change. Thought I'd mention it here so you can make sure you're aware of potential changes needed in this space. I filed an issue to track: swiftlang/swift-build#114 |
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-04-08.
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,
You will most likely want to build the standard toolchain. You can do this in two phases: first building the bootstrap toolchain, then use that toolchain to build the standard toolchain.
First, save the following json file for the
update-checkout
script (compacted for simplicity):Save the following
build-script
invocation to a shell script to build the bootstrap toolchain:Save the following
build-script
invocation to a shell script to build the standard toolchain:Check out
swiftlang/swift
.Use the following update-checkout command:
Manual changes required:
llvm-project
on arm64 builds, use Fix crash lowering stack guard on OpenBSD/aarch64. llvm/llvm-project#125416swift
,include/swift/AST/SILOptions.h
so thatEnableOSSAModules
isfalse
.stdlib/public/Synchronization/Mutex.swift
usingpthread_mutex_t?
, or use the 5.10 version of Foundation.stdlib/public/Synchronization/CMakeLists.txt
.pthread_mutex_t
could be a value type with internal pointers, this should be safe enough for now since OpenBSD uses a pointer forpthread_mutex_t
.swift-corelibs-foundation
is the one prior toMutex
being adopted.swift-foundation
, addtarget_compile_options(FoundationEssentials PRIVATE "SHELL:$<$<COMPILE_LANGUAGE:Swift>:-Xfrontend -disable-large-loadable-types-reg2mem>")
toSources/FoundationEssentials/CMakeLists.txt
or use a non-Release build type.Other manual changes not described here may be required and will eventually be upstreamed or discussed further here.
-z origin
needs to be plumbed through in more places; work around by setting LD_LIBRARY_PATH.swiftc -num-threads
can be memory-hungry and cause lockups, and ld.so warnings about recursive allocation errors occur sometimesamd64
at some point.The text was updated successfully, but these errors were encountered: