Skip to content

Support Debian 11 and Debian 12 distributions in the generator #203

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

Merged

Conversation

xtremekforever
Copy link
Contributor

@xtremekforever xtremekforever commented Mar 24, 2025

This completes #116 and can be used to generate Debian Swift SDKs either by downloading dependencies from mirrors directly or from containers.

  • Added Debian bullseye and bookworm to LinuxDistribution and modded SwiftSDKGenerator+Download to work downloading both Ubuntu and Debian packages from their respective mirrors.
  • Swift SDKs can be generated from Docker using the swift:*-bookworm container for Debian 12, but for Debian 11 you must create the container yourself/manually put the Swift toolchain into it.
  • Added special handling in VersionsConfiguration so that if Debian 11 (bullseye) is selected, the Ubuntu 20.04 toolchain is downloaded. If Debian 12 (bookworm) is selected for Swift 5.9.* or Swift 5.10, the Ubuntu 22.04 toolchain is used instead. https://askubuntu.com/a/445496
  • Added tests for the special handling in LinuxRecipeTests.testItemsToDownloadForDebianTargets() to ensure the correct toolchain is selected.

To use:

$ swift run swift-sdk-generator make-linux-sdk --linux-distribution-name debian --linux-distribution-version 11
$ swift run swift-sdk-generator make-linux-sdk --linux-distribution-name debian --linux-distribution-version 12
$ swift run swift-sdk-generator make-linux-sdk --linux-distribution-name debian --linux-distribution-version 12 --with-docker

I also added EndToEndTests for all Debian supported combinations, resulting in another 30GB of generated Swift SDKs:

    2.1 GiB [####################] /debian_12_x86_64_6.0.3-RELEASE_with-docker.artifactbundle
    2.1 GiB [################### ] /debian_12_aarch64_6.0.3-RELEASE_with-docker.artifactbundle
    2.0 GiB [##################  ] /debian_12_x86_64_5.10.1-RELEASE_with-docker.artifactbundle
    1.9 GiB [#################   ] /debian_12_x86_64_6.0.3-RELEASE.artifactbundle
    1.9 GiB [#################   ] /debian_12_aarch64_6.0.3-RELEASE.artifactbundle
    1.9 GiB [#################   ] /debian_11_x86_64_6.0.3-RELEASE.artifactbundle
    1.9 GiB [#################   ] /debian_12_aarch64_5.10.1-RELEASE_with-docker.artifactbundle
    1.9 GiB [#################   ] /debian_11_aarch64_6.0.3-RELEASE.artifactbundle
    1.8 GiB [################    ] /debian_12_x86_64_5.10.1-RELEASE.artifactbundle
    1.7 GiB [################    ] /debian_12_aarch64_5.10.1-RELEASE.artifactbundle
    1.7 GiB [################    ] /debian_11_x86_64_5.10.1-RELEASE.artifactbundle
    1.7 GiB [###############     ] /debian_11_aarch64_5.10.1-RELEASE.artifactbundle
    1.7 GiB [###############     ] /debian_12_x86_64_5.9.2-RELEASE.artifactbundle
    1.7 GiB [###############     ] /debian_12_aarch64_5.9.2-RELEASE.artifactbundle
    1.7 GiB [###############     ] /debian_11_x86_64_5.9.2-RELEASE.artifactbundle
    1.6 GiB [###############     ] /debian_11_aarch64_5.9.2-RELEASE.artifactbundle

To make this work properly, I modded the targetSwift path in DownloadableArtifacts to use the swiftPlatform name in the file name to avoid the issues I saw with the EndToEndTests, where the *.tar.gz files would get corrupted when trying to download a different version of the target Swift on top of the existing file. Now, they look like this:

target_swift_5.10.1-RELEASE_debian12_aarch64.tar.gz     target_swift_5.9.2-RELEASE_ubuntu22.04_aarch64.tar.gz
target_swift_5.10.1-RELEASE_debian12_x86_64.tar.gz      target_swift_5.9.2-RELEASE_ubuntu22.04_x86_64.tar.gz
target_swift_5.10.1-RELEASE_ubuntu20.04_aarch64.tar.gz  target_swift_6.0.3-RELEASE_debian12_aarch64.tar.gz
target_swift_5.10.1-RELEASE_ubuntu20.04_x86_64.tar.gz   target_swift_6.0.3-RELEASE_debian12_x86_64.tar.gz
target_swift_5.10-RELEASE_ubuntu20.04_aarch64.tar.gz    target_swift_6.0.3-RELEASE_ubuntu20.04_aarch64.tar.gz
target_swift_5.9.2-RELEASE_ubuntu20.04_aarch64.tar.gz   target_swift_6.0.3-RELEASE_ubuntu20.04_x86_64.tar.gz
target_swift_5.9.2-RELEASE_ubuntu20.04_x86_64.tar.gz

Have at it @MaxDesiatov @euanh

@MaxDesiatov MaxDesiatov requested a review from euanh March 24, 2025 17:38
@MaxDesiatov MaxDesiatov added the enhancement New feature or request label Mar 24, 2025
@MaxDesiatov
Copy link
Contributor

@swift-ci test

@MaxDesiatov
Copy link
Contributor

@swift-ci test

@xtremekforever
Copy link
Contributor Author

I updated the README.md since I realized it didn't reflect the fact that the generator supports Debian 11 and 12 now.

@MaxDesiatov
Copy link
Contributor

@swift-ci test

 - This is required since Debian 11 has a different layout than other Ubuntu/Debian versions.
@xtremekforever
Copy link
Contributor Author

xtremekforever commented Mar 26, 2025

I found that Debian 11 has a different layout for where libraries are with the /lib and /lib64 directories when building from the container image. /lib64/ld-linux-x86-64.so.2 is symlinked to ../lib/x86_64-linux-gnu/ld-2.31.so in the sysroot, which means that we must copy over the /lib/x86_64-linux-gnu directory from the container as well to get a properly working sysroot for Debian 11.

I've added changes for this that should just apply to Debian 11- and also ran the EndToEndTests for containers to make sure other containers are not affected.

@MaxDesiatov
Copy link
Contributor

@swift-ci test

@MaxDesiatov
Copy link
Contributor

@swift-ci test linux

@xtremekforever
Copy link
Contributor Author

@swift-ci test linux

Looks like it doesn't like the switch syntax I'm using on 5.8:

/__w/swift-sdk-generator/swift-sdk-generator/Sources/SwiftSDKGenerator/Generator/SwiftSDKGenerator+Copy.swift:86:28: error: expected initial value after '='
          let archSubpath =

Should be a simple fix.

@MaxDesiatov
Copy link
Contributor

@swift-ci test

Copy link
Contributor

@MaxDesiatov MaxDesiatov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@MaxDesiatov
Copy link
Contributor

I'd prefer to hold off merging this until @euanh has a moment to review it, unless this PR is blocking some subsequent urgent PRs that you plan to submit?

@xtremekforever
Copy link
Contributor Author

xtremekforever commented Mar 31, 2025

I'd prefer to hold off merging this until @euanh has a moment to review it, unless this PR is blocking some subsequent urgent PRs that you plan to submit?

This isn't urgent for me. I am using the stuff in this PR in my https://github.com/xtremekforever/swift-linux-cross-sdks repo, but I'm still working out being able to build Swift SDKs for bullseye for x86_64 and aarch64.

In case you didn't know, in this repo I'm basically working on a workflow for building Swift SDKs for all supported versions of Swift for x86_64, aarch64, and armv7 using the swift-sdk-generator. So to have some "pre-built" Swift SDKs out in the wild. However, there's still some ways to go as I still want to be able to build test binaries with each Swift SDK and test them on real targets for all of the above architectures, which means hooking up some real Raspberry PIs in to run the binaries for me. Lofty goals, long path...but it also helps in discovering issues in the swift-sdk-generator as I use it to generate different Swift SDKs here.

So yeah, @MaxDesiatov there aren't any more PRs for me here yet. I do plan to look at #197 after this PR is in, since I'll eventually need it, but I'm not there yet.

@MaxDesiatov
Copy link
Contributor

@swift-ci test

@MaxDesiatov
Copy link
Contributor

@euanh friendly ping

@euanh
Copy link
Contributor

euanh commented Apr 16, 2025

@swift-ci test

@MaxDesiatov MaxDesiatov merged commit ed6a85b into swiftlang:main Apr 16, 2025
19 checks passed
@xtremekforever xtremekforever deleted the #116-support-debian-distributions branch April 16, 2025 10:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants