Static Linking Blog Post Instructions not working

Using Swift
1

I'm trying to build a utility for linux with static linking using this blog post. However, I'm getting an error on the first sdk install step (This output is after I downloaded the file manually for troubleshooting, but the error is identical):

root@74397c1150f2:/mounted# swift sdk install swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz --checksum 67f765e0030e661a7450f7e4877cfe008db4f57f177d5a08a6e26fd661cdd0bd
Swift SDK bundle at `swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz` is assumed to be an archive, unpacking...
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)"

Just on the off chance it was being persnickety, I tried to build anyways, but unsurprisingly got an error:

root@74397c1150f2:/mounted# swift build -c release --swift-sdk aarch64-swift-linux-musl
warning: Couldn't parse `info.json` manifest of a Swift SDK bundle at /root/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle: ArtifactsArchive info.json not found at '/root/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle'
error: No valid Swift SDK bundles found at /root/.swiftpm/swift-sdks.

If I'm not mistaken, something is misconfigured in these sdk files, the toolchain, or the blog post instructions are out of date.

Is there a chance I'm holding it wrong? I can't see how I might have messed up these simple instructions.

My current swift version:

root@74397c1150f2:/mounted# swift --version
Swift version 6.0.3 (swift-6.0.3-RELEASE)
Target: aarch64-unknown-linux-gnu

I can't think of any other relevant troubleshooting info, but feel free to ask.

2

I've seen a similar problem before: swiftPM puts the SDK bundle in /tmp and tries to unpack it there, so if you have any kind of limit less than a couple GiB on that directory, as I did, it will fail with inscrutable errors. If that's what you're hitting too, deleting other files in /tmp or raising its limit may help you get past this.

Btw, swift sdk list will tell you what SDKs are installed, no need to compile to check that.

3

swift sdk list gives me the same error as trying to build:

root@74397c1150f2:/mounted# swift sdk list
No Swift SDKs are currently installed.
warning: Couldn't parse `info.json` manifest of a Swift SDK bundle at /root/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle: ArtifactsArchive info.json not found at '/root/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle'

I CAN however run swift sdk remove

root@74397c1150f2:/mounted# swift sdk remove swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle
Swift SDK bundle at path `/root/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle` was successfully removed from the file system.

And I don't have any limits on /tmp. I'm not even sure how I'd do that (short of making a mount in fstab? - It's just a regular directory for me)

4

Oooh a clue! I downloaded the file and just unarchived it manually.

I saw many files in the verbose listing that weren't in the previous attempt, including the mythical info.json file.

Additionally, I got this:

root@74397c1150f2:/mounted# tar -xf swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz
tar: swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/aarch64/usr/lib/swift_static/clang: Cannot open: Permission denied
tar: swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/x86_64/usr/lib/swift_static/clang: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
5

The plot thickens - it uncompresses flawlessly on another machine.

What could be special about the swift docker image that would prevent it from unarchiving fully?!

6

Well - it now kinda works when I point to a correctly unarchived directory instead of the compressed archive.

I say "kinda" because I'm now getting errors when using a package that has sqlite dependencies, which I assume is related to musl vs glibc... SO this issue is probably resolved...

7

Those are symbolic links in the SDK: does Docker not allow those?

8

It should... It's basically a linux environment identical to a full linux machine, just with a few sandboxy permission restrictions. Not that it should make a difference, but if it does, I'm actually using podman (which is a drop in-ish replacement for docker)

9

What extra-doesn't-make-sense to me is that I'm uncompressing, aka writing. Why am I getting an error that it can't be read?

jk - the error is about opening, which is obviously used for both reads and writes.

10

I just tested re-creating the links manually, rearchiving, then unarchiving again and ran into the same issue. :person_shrugging: