Summary
`projects/swift.org/package.yml` has the linux/x86-64 and linux/aarch64 platforms commented out (lines 16-17) with the cryptic note:
```yaml
It is ready to run on linux. It going to work with ubuntu 22.04,
and not with debian-buster and tests going to fail
```
This issue documents the actual constraint and the available unblocking paths so it can be tracked and prioritized.
Root cause
Apple compiles their Linux Swift toolchain against Ubuntu 22.04 LTS (glibc 2.35). pantry's brewkit Linux CI builder uses an older container (debian-buster-class, glibc 2.28). Running the vendored Apple binary against the older glibc fails at the dynamic linker:
```
./swift: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
```
The recipe ITSELF is fully ready for Linux — `build.script` handles the linux branch (line 47), deps are declared (lines 19-27), `provides:.linux:` lists ~25 binaries (lines 95-136). The only block is the CI runner's libc version.
Available unblocking paths
-
Bump brewkit's Linux container to ubuntu-22.04. Systemic change affecting all Linux bottles — requires maintainer buy-in. May break recipes that build cleanly against older glibc symbols (a TINY minority — most modern recipes target glibc 2.31+ already).
-
Self-hosted ubuntu-22.04 runner with optional 32GB+ RAM, for full from-source Swift build. The official from-source build needs 30-60 GB RAM at link, so any "build Swift from source" path is gated on bigger runners. Apple's CI uses 1.5 TB RAM machines.
-
Pin to older Swift on older Ubuntu. Apple ships Ubuntu 18.04 binaries up through Swift 5.7. Could maintain swift.org-5.7 as a separate sub-recipe pinned to that line. Trade-off: users get a 2022-era Swift on Linux.
-
Pantry-bundled glibc + LD_LIBRARY_PATH overlay. If pantry ships its own modern glibc as a bottle (`gnu.org/glibc-host-independent` work in progress), any vendored binary can declare `gnu.org/glibc: '>=2.35'` as a runtime dep, and pkgx's env composer would materialize that glibc alongside swift. The vendored binary would dynamic-load pantry's glibc rather than the system's. The most elegant long-term answer, but depends on the broader host-independent-glibc effort landing first.
Recommendation
Option 1 (container bump) is the smallest near-term move with the biggest unlock. Option 4 is the right long-term direction. Options 2 and 3 carry larger downsides.
Related
What I am doing in parallel
While Linux is gated, I'm enriching pantry's darwin Swift ecosystem (recently filed swiftly #13126; planning Tuist, SwiftGen, Carthage recipes). All these are pure-Swift CLI tools built against the existing darwin swift.org compiler — they're independent of the Linux-bottling decision.
Summary
`projects/swift.org/package.yml` has the linux/x86-64 and linux/aarch64 platforms commented out (lines 16-17) with the cryptic note:
```yaml
It is ready to run on linux. It going to work with ubuntu 22.04,
and not with debian-buster and tests going to fail
```
This issue documents the actual constraint and the available unblocking paths so it can be tracked and prioritized.
Root cause
Apple compiles their Linux Swift toolchain against Ubuntu 22.04 LTS (glibc 2.35). pantry's brewkit Linux CI builder uses an older container (debian-buster-class, glibc 2.28). Running the vendored Apple binary against the older glibc fails at the dynamic linker:
```
./swift: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
```
The recipe ITSELF is fully ready for Linux — `build.script` handles the linux branch (line 47), deps are declared (lines 19-27), `provides:.linux:` lists ~25 binaries (lines 95-136). The only block is the CI runner's libc version.
Available unblocking paths
Bump brewkit's Linux container to ubuntu-22.04. Systemic change affecting all Linux bottles — requires maintainer buy-in. May break recipes that build cleanly against older glibc symbols (a TINY minority — most modern recipes target glibc 2.31+ already).
Self-hosted ubuntu-22.04 runner with optional 32GB+ RAM, for full from-source Swift build. The official from-source build needs 30-60 GB RAM at link, so any "build Swift from source" path is gated on bigger runners. Apple's CI uses 1.5 TB RAM machines.
Pin to older Swift on older Ubuntu. Apple ships Ubuntu 18.04 binaries up through Swift 5.7. Could maintain swift.org-5.7 as a separate sub-recipe pinned to that line. Trade-off: users get a 2022-era Swift on Linux.
Pantry-bundled glibc + LD_LIBRARY_PATH overlay. If pantry ships its own modern glibc as a bottle (`gnu.org/glibc-host-independent` work in progress), any vendored binary can declare `gnu.org/glibc: '>=2.35'` as a runtime dep, and pkgx's env composer would materialize that glibc alongside swift. The vendored binary would dynamic-load pantry's glibc rather than the system's. The most elegant long-term answer, but depends on the broader host-independent-glibc effort landing first.
Recommendation
Option 1 (container bump) is the smallest near-term move with the biggest unlock. Option 4 is the right long-term direction. Options 2 and 3 carry larger downsides.
Related
pkgx swift: download failure 404 #5930 (swift download 404 — linux is intentionally not built; this issue is the structural reason)What I am doing in parallel
While Linux is gated, I'm enriching pantry's darwin Swift ecosystem (recently filed swiftly #13126; planning Tuist, SwiftGen, Carthage recipes). All these are pure-Swift CLI tools built against the existing darwin swift.org compiler — they're independent of the Linux-bottling decision.