Skip to content

Build on OpenBSD #114

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.

Sign up for GitHub

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

Jump to bottom
Closed
jakepetroules opened this issue Feb 7, 2025 · 5 comments · Fixed by #365
Closed

Build on OpenBSD #114

jakepetroules opened this issue Feb 7, 2025 · 5 comments · Fixed by #365
Assignees
@3405691582

Comments

@jakepetroules
Copy link
Collaborator

jakepetroules commented Feb 7, 2025 •
edited
Loading

Building on OpenBSD hosts, but not necessarily building for a OpenBSD target on a OpenBSD host.
@jakepetroules
Copy link
Collaborator Author

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

@jakepetroules jakepetroules mentioned this issue Feb 7, 2025
Open
@3405691582
Copy link
Member

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 added a commit to 3405691582/swift-build that referenced this issue Mar 26, 2025
@3405691582
OpenBSD support.
63182a1 
* Ensure the swift-crypto dependency is conditioned for the platform.

  The relevant swift-crypto changes are not landed upstream yet, but
  when they are, this picks up the dependency.

* Cast timestamps to time_t.

  This is done unconditionally here, because the standard specifies
  that `tv_sec` in `timespec` has type `time_t`, and doing so avoids a
  type mismatch error on the platform.

* Since pthread types are pointers here, make the usual changes to
  capture the fact they are optional types on the Swift side.

Fixes swiftlang#114.
3405691582 added a commit to 3405691582/swift-build that referenced this issue Mar 29, 2025
@3405691582
OpenBSD support.
24eb0e1 
* Ensure the swift-crypto dependency is conditioned for the platform.

  The relevant swift-crypto changes are not landed upstream yet, but
  when they are, this picks up the dependency.

* Cast timestamps to time_t.

  This is done unconditionally here, because the standard specifies
  that `tv_sec` in `timespec` has type `time_t`, and doing so avoids a
  type mismatch error on the platform.

* Since pthread types are pointers here, make the usual changes to
  capture the fact they are optional types on the Swift side.

So far, this has been the only set of changes that have seemed necessary.

Fixes swiftlang#114.
@3405691582 3405691582 mentioned this issue Mar 29, 2025
Merged
owenv pushed a commit that referenced this issue Mar 31, 2025
@3405691582
OpenBSD support. (#365)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
1d45a98 
* Ensure the swift-crypto dependency is conditioned for the platform.

  The relevant swift-crypto changes are not landed upstream yet, but
  when they are, this picks up the dependency.

* Cast timestamps to time_t.

  This is done unconditionally here, because the standard specifies
  that `tv_sec` in `timespec` has type `time_t`, and doing so avoids a
  type mismatch error on the platform.

* Since pthread types are pointers here, make the usual changes to
  capture the fact they are optional types on the Swift side.

So far, this has been the only set of changes that have seemed necessary.

Fixes #114.
@jakepetroules jakepetroules changed the title Add OpenBSD support Build on OpenBSD Mar 31, 2025
@3405691582
Copy link
Member

3405691582 commented Apr 15, 2025 •
edited
Loading

@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
Copy link
Collaborator Author

@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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@3405691582 3405691582

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

OpenBSD support. 3405691582/swift-build
2 participants
@jakepetroules @3405691582