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
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: