Skip to content

Amazon Linux 2 Support for Swift Build #441

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

Open
cmcgee1024 opened this issue Apr 25, 2025 · 3 comments · May be fixed by #584
Open

Amazon Linux 2 Support for Swift Build #441

cmcgee1024 opened this issue Apr 25, 2025 · 3 comments · May be fixed by #584

Comments

@cmcgee1024
Copy link
Member

Amazon Linux 2 is a little more challenging to support than other Linux distributions. In particular, there is a missing implementation of posix_spawn_file_actions_addchdir for the version of glibc available there. There could be other issues with Swift Build support for that platform too, but this is the most immediate problem.

@jakepetroules
Copy link
Collaborator

The main thing in Swift Build is our use of Foundation Process (NSTask), which has an implementation of setting the working directory which is NOT thread safe on platforms lacking posix_spawn_file_actions_addchdir (Amazon Linux 2, OpenBSD, QNX, and older Android versions). To solve this we can adopt swift-subprocess, which has a fork/exec fallback path for environments where posix_spawn_file_actions_addchdir is unavailable.

The other one is llbuild's process spawning code, which has a hard dependency on posix_spawn_file_actions_addchdir, and needs to be tracked separately on the llbuild project.

@cmcgee1024
Copy link
Member Author

See swiftlang/swift-llbuild#980 for the llbuild portion.

@jakepetroules
Copy link
Collaborator

The underlying llbuild issue was resolved, and #545 (#551 for 6.2) unskipped all of the relevant tests.

There are a 4 tests which are still skipped because they use Foundation.Process instead of llbuild, but those are test-only issues and don't impact build operations.

There is also a workaround in place for parts of task construction which also go through Foundation.Process rather than llbuild:

// FIXME: Work around lack of thread-safe working directory support in Foundation (Amazon Linux 2, OpenBSD). Executing processes in the current working directory is less deterministic, but all of the clients which use this class are generally not expected to be sensitive to the working directory anyways. This workaround can be removed once we drop support for Amazon Linux 2 and/or adopt swift-subprocess and/or Foundation.Process's working directory support is made thread safe.

I think I'll leave this open until those pieces are fully resolved too.

jakepetroules added a commit that referenced this issue Jun 13, 2025
This fully resolves working directory thread safety issues with subprocess spawning across all platforms. For now, subprocess is adopted conditionally in order to continue building in certain environments where the Subprocess module may not be available, in which case we fall back to Foundation Process.

Closes #441
@jakepetroules jakepetroules linked a pull request Jun 13, 2025 that will close this issue
jakepetroules added a commit that referenced this issue Jun 13, 2025
This fully resolves working directory thread safety issues with subprocess spawning across all platforms. For now, subprocess is adopted conditionally in order to continue building in certain environments where the Subprocess module may not be available, in which case we fall back to Foundation Process.

Closes #441
jakepetroules added a commit that referenced this issue Jun 13, 2025
This fully resolves working directory thread safety issues with subprocess spawning across all platforms. For now, subprocess is adopted conditionally in order to continue building in certain environments where the Subprocess module may not be available, in which case we fall back to Foundation Process.

Closes #441
jakepetroules added a commit that referenced this issue Jun 14, 2025
This fully resolves working directory thread safety issues with subprocess spawning across all platforms. For now, subprocess is adopted conditionally in order to continue building in certain environments where the Subprocess module may not be available, in which case we fall back to Foundation Process.

Closes #441
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants