Creating an AmazonLinux2 Swift SDK fails #138
Assignees
Labels
bug
Something isn't working
Comments
|
|
Hi @sebsto I can reproduce this problem.
This is the default, you can override it using the
My initial thought was that this was also caused by the SDK generator's default assumption that it is working with an Ubuntu-derived distribution, whereas it seems Amazon Linux is based on CentOS. I had hoped that specifying |
These messages are annoying but harmless and should go away in future. |
|
Yes, that one was fixed in swiftlang/swift#76545 |
The problem here is that we are copying I'll fix this in the generator, but as a workaround we can touch up the generated SDK and get it working: |
|
This works for I'll dig into that next. |
|
Thank you for the quick initial investigation. |
|
Yes, I've removed it above. Sorry about that. |
sebsto
changed the title
This was referenced Oct 31, 2024
euanh
added a commit
that referenced
this issue
Nov 11, 2024
…m CI (#144) Building an SDK requires running the sdk-generator with `swift run swift-sdk-generator`. This takes a lock on `.build`, but if the tests are being run by `swift test` the outer Swift Package Manager instance will already hold this lock, causing the test to deadlock. We can avoid this by giving the `swift run swift-sdk-generator` instance its own scratch directory. This PR consolidates the code which builds SDKs in one function, then runs each SDK build with its own temporary scratch directory. This avoids the deadlock on the `.build` directory when run under `swift test`. The tests continue to pass when run under Xcode, which was not affected by the deadlock because it works in a separate scratch directory. :warning: **The tests cannot currently run in CI because SDK generator cannot use the HTTP proxy to download packages.** This PR allows the tests to be run locally with `swift test` but skips them when running in the CI. When the downloading problem is solved, the tests can be enabled in CI as well. :warning: RHEL-based Swift 6.0 SDKs built from container images currently do not currently work, as reported in #138. This PR makes it possible to run the test locally under `swift test` while working on this problem, to prevent regressions such as #141. Fixes #143
euanh
added a commit
to euanh/swift-sdk-generator
that referenced
this issue
Nov 18, 2024
Swift Package Manager's linker flag handling changed between 5.9 and 5.10. The flags which work for 5.9 cause linking failures 5.10 and later, and vice versa: swiftlang/swift-package-manager#7222 This commit generates workaround flags for 5.9 and new-style flags for all other versions. The EndToEnd tests currently cannot run in CI, so this change was tested locally. (Issue swiftlang#145) * The basic 'hello world' example generated by `swift package init` built succesfully with 5.9.2, 5.10.1 and 6.0.2 SDKs on x86_64 and aarch64. * A more complex example using Vapor built succesfully with 5.9.2, 5.10.1. 6.0.2 failed because of the CShims problem reported in Issue swiftlang#138.
euanh
added a commit
to euanh/swift-sdk-generator
that referenced
this issue
Nov 18, 2024
Swift Package Manager's linker flag handling changed between 5.9 and 5.10. The flags which work for 5.9 cause linking failures 5.10 and later, and vice versa: swiftlang/swift-package-manager#7222 This commit generates workaround flags for 5.9 and new-style flags for all other versions. The EndToEnd tests currently cannot run in CI, so this change was tested locally. (Issue swiftlang#145) * The basic 'hello world' example generated by `swift package init` built successfully with 5.9.2, 5.10.1 and 6.0.2 SDKs on x86_64 and aarch64. * A more complex example using Vapor built succesfully with 5.9.2, 5.10.1. 6.0.2 failed because of the CShims problem reported in Issue swiftlang#138.
euanh
added a commit
that referenced
this issue
Nov 18, 2024
Swift Package Manager's linker flag handling changed between 5.9 and 5.10. The flags which work for 5.9 cause linking failures 5.10 and later, and vice versa: swiftlang/swift-package-manager#7222 This commit generates workaround flags for 5.9 and new-style flags for all other versions. The EndToEnd tests currently cannot run in CI, so this change was tested locally. (Issue #145) * The basic 'hello world' example generated by `swift package init` built successfully with 5.9.2, 5.10.1 and 6.0.2 SDKs on x86_64 and aarch64. * A more complex example using Vapor built succesfully with 5.9.2, 5.10.1. 6.0.2 failed because of the CShims problem reported in Issue #138.
|
@sebsto This should work now. Build the SDK: Build a container image: There will still be warnings about the C library, |
|
@euanh why does this need to be generated using the rhel distribution? Is it just that the SDK generator doesn't support Amazon Linux ? |
|
Amazon Linux is based on RHEL, so if certain logic of Swift SDK creation can be shared between distributions instead of maintaining two separate copies, why not share those? |
|
Okay, clear :) |
MaxDesiatov
changed the title
|
I'm trying to generate an Amazon Linux 2 Swift SDK today using this command: And I'm getting this error now: It seems that generating the Swift SDK for aarch64 does work, so it's the x86_64 one that's failing. Shall we have a look at why? |
|
I just test this on Arm and it seems to work. |
|
@euanh Building the SDK works - thank you (at least on Arm, @xtremekforever reported an error on x64) However, compiling a project with the SDK fails with this error : Steps to reproduce : I'm using Swift 6.0.3 |
|
@sebsto I've seen this whenever I don't use the open source Swift toolchain on macOS. For some reason the Swift SDK doesn't like being compiled on macOS without the open source toolchain. So, to fix this, you can run the generator with the |
|
Thank you @xtremekforever. It compiles now. |
@sebsto Since #173 we are no longer including the host toolchain in the SDK by default. This matches the behaviour of the Static Linux SDK. https://www.swift.org/documentation/articles/static-linux-getting-started.html#installing-the-sdk You can either use The reason for this is a |
This warning has been present for a while and you can ignore it. swiftlang/swift#76545 should fix it, but that change might not yet be in the build you are using. |
xtremekforever
added a commit
to xtremekforever/swift-sdk-generator
that referenced
this issue
Mar 7, 2025
xtremekforever
added a commit
to xtremekforever/swift-sdk-generator
that referenced
this issue
Mar 11, 2025
MaxDesiatov
added a commit
that referenced
this issue
Mar 12, 2025
… distributions (#195) This fixes the final issue we saw with #138 where there was an error generating an `amazonlinux2` Swift SDK for x86_64. This was fixed by removing 32-bit libraries from the sysroot imported from the container for RHEL-based distributions. To test this, I've added EndToEndTests for `amazonlinux2` and `fedora39` on top of the existing RHEL UBI9 tests. All of these depend on pulling from containers to test: ``` 2.1 GiB [#################] /fedora39_aarch64_6.0.3-RELEASE_with-docker.artifactbundle 2.0 GiB [################ ] /fedora39_x86_64_6.0.3-RELEASE_with-docker.artifactbundle 2.0 GiB [################ ] /amazonlinux2_aarch64_6.0.3-RELEASE_with-docker.artifactbundle 1.9 GiB [############### ] /amazonlinux2_x86_64_6.0.3-RELEASE_with-docker.artifactbundle 1.9 GiB [############### ] /rhel_ubi9_x86_64_6.0.3-RELEASE_with-docker.artifactbundle 1.9 GiB [############### ] /rhel_ubi9_aarch64_6.0.3-RELEASE_with-docker.artifactbundle 1.8 GiB [############### ] /fedora39_x86_64_5.10.1-RELEASE_with-docker.artifactbundle 1.8 GiB [############### ] /fedora39_aarch64_5.10.1-RELEASE_with-docker.artifactbundle 1.8 GiB [############## ] /amazonlinux2_aarch64_5.10.1-RELEASE_with-docker.artifactbundle 1.8 GiB [############## ] /amazonlinux2_x86_64_5.10.1-RELEASE_with-docker.artifactbundle 1.7 GiB [############## ] /rhel_ubi9_x86_64_5.10.1-RELEASE_with-docker.artifactbundle 1.7 GiB [############## ] /rhel_ubi9_aarch64_5.10.1-RELEASE_with-docker.artifactbundle 1.7 GiB [############## ] /amazonlinux2_aarch64_5.9.2-RELEASE_with-docker.artifactbundle 1.7 GiB [############# ] /amazonlinux2_x86_64_5.9.2-RELEASE_with-docker.artifactbundle 1.7 GiB [############# ] /rhel_ubi9_x86_64_5.9.2-RELEASE_with-docker.artifactbundle 1.7 GiB [############# ] /rhel_ubi9_aarch64_5.9.2-RELEASE_with-docker.artifactbundle ``` All of these Swift SDKs take 30GB of disk space. --------- Co-authored-by: Max Desiatov <[email protected]>
|
Since we can now generate Amazon Linux 2 Swift SDKs and they both work: Can we consider this ticket closed? @sebsto |
|
Thank you @euanh and @xtremekforever, closing this now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I wonder if it would be possible to generate an Amazon Linux 2 SDK ?
When I try to follow instruction to generate a SDK with a docker image, it generates files with the name
UbuntuI surely missed something.
The text was updated successfully, but these errors were encountered: