Arch Linux User Repository

With 6.4.0-1, swift build on SwiftPM's new default engine (swiftbuild) fails for any package that depends on one using package access (swift-log, swift-crypto, …):

error: the package access level used on 'Lock' requires a package name; set it with the compiler flag -package-name

It's caused by how this package lays out the toolchain, not by Swift itself. swiftbuild assumes the toolchain's root directory is named usr. This PKGBUILD copies the tarball's usr/* into /usr/lib/swift/, so the root is named swift. swiftbuild then looks for its files in a nonexistent place (/usr/lib/usr/lib/swift/... shows up in the failing command lines), silently drops -package-name, and the build fails.

I tested this with the same swift-6.4.0-RELEASE-ubi10.tar.gz and a minimal package that depends only on swift-log:

• Tarball's usr/ left as-is: builds, including when swift is called through a symlink.
• Tarball's usr/ renamed to anything else (e.g. foo/), nothing else changed: fails.
• Tarball's usr/* flattened into <prefix>/lib/swift/, as this PKGBUILD does: fails.
• Tarball's usr/ kept intact at <prefix>/lib/swift/usr/ and symlinked into a bin dir: builds.

Could the package keep the usr directory? I built 6.4.0-2 locally with this change, and both the minimal package and a real project (CodexBar) then compile on the default engine:

-  cp -Ppr "${srcdir}/swift-$pkgver-RELEASE-ubi10${_archsuffix}"/usr/* "${pkgdir}/usr/lib/swift"
+  cp -Ppr "${srcdir}/swift-$pkgver-RELEASE-ubi10${_archsuffix}"/usr "${pkgdir}/usr/lib/swift/usr"
 ...
-    ln -s "/usr/lib/swift/bin/$bin" "${pkgdir}/usr/bin/$bin"
+    ln -s "/usr/lib/swift/usr/bin/$bin" "${pkgdir}/usr/bin/$bin"
 ...
-  echo '/usr/lib/swift/lib/swift/linux' >> "${pkgdir}/etc/ld.so.conf.d/swift.conf"
+  echo '/usr/lib/swift/usr/lib/swift/linux' >> "${pkgdir}/etc/ld.so.conf.d/swift.conf"

find_elf_only searches /usr/lib/swift recursively, so the patchelf step still finds everything. Anything that hardcodes /usr/lib/swift/bin/ would need updating.

Caveat for anyone moving to the new engine: even with the layout fixed, swift build --static-swift-stdlib on swiftbuild fails at the final link for anything that uses Foundation (undefined reference to 'CFStringCreateWithCString', …). That bug is upstream in Swift 6.4.0, not in this package (swift-build#1764). It has been fixed and backported for 6.4.2. Until then, static builds need --build-system native, or need to link the Swift runtime dynamically instead.

Workaround for both issues until then: swift build --build-system native.

Adding "-cxx-interoperability-mode=default" to a simple hello world miserably fails, when "import Foundation" is used:

<module-includes>:1:10: note: in file included from <module-includes>:1:
1 | #include "_FoundationCShims.h"
  |          `- note: in file included from <module-includes>:1:
2 | 

/usr/lib/swift/lib/swift/_FoundationCShims/_FoundationCShims.h:17:10: note: in file included from /usr/lib/swift/lib/swift/_FoundationCShims/_FoundationCShims.h:17:
15 | 
16 | #include "_CShimsTargetConditionals.h"
17 | #include "_CStdlib.h"
   |          `- note: in file included from /usr/lib/swift/lib/swift/_FoundationCShims/_FoundationCShims.h:17:
18 | #include "CFUniCharBitmapData.inc.h"
19 | #include "CFUniCharBitmapData.h"

/usr/lib/swift/lib/swift/_FoundationCShims/_CStdlib.h:55:10: note: in file included from /usr/lib/swift/lib/swift/_FoundationCShims/_CStdlib.h:55:
 53 | 
 54 | #if __has_include(<math.h>)
 55 | #include <math.h>
    |          `- note: in file included from /usr/lib/swift/lib/swift/_FoundationCShims/_CStdlib.h:55:
 56 | #endif
 57 | 

/usr/lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1/math.h:36:11: note: in file included from /usr/lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1/math.h:36:
 34 | #define _GLIBCXX_MATH_H 1
 35 | 
 36 | # include <cmath>
    |           `- note: in file included from /usr/lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1/math.h:36:
 37 | 
 38 | using std::abs;

I see swift and swiftc are installed to /usr/bin, but almost everything else is installed to /usr/lib, which leads to odd paths like this:

/usr/lib/swift/bin/clang
/usr/lib/swift/include/SourceKit/sourcekitd.h
/usr/lib/swift/lib/swift/CoreFoundation/CFData.h
/usr/lib/swift/share/doc/swift/diagnostics/temporary-pointers.md

Shouldn't these be in /usr/share/swift and so on?

Looks like it needs to depend on Python 3.9 for the swift repl command.

$ swift repl  
/usr/lib/swift/bin/lldb: error while loading shared libraries: libpython3.9.so.1.0: cannot open shared object file: No such file or directory

I am getting:

> swift build
/usr/lib/swift/bin/swift-build: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

I guess this needs an update after the latest libxml2 release.

edit: thanks! With swift-bin 6.1-2 and the dependency to libxml2-legacy it is working again.

I have had some success repackaging the Ubuntu binaries both for x86_64 and aarch64: https://github.com/archsink/pkgbuilds/blob/e23d84133af19fb642898a6753857f79abc80f07/swift-bin/PKGBUILD

Could probably use some more battle-testing though, I have only checked that some very simple programs compile.

Is there a chance to support aarch64? The packages provided on Swift.org for Ubuntu, Red Hat and Amazon Linux all have a binary version for aarch64. Just the CentOS version used in this AUR package unfortunately does not have one.

Would it be possible to change to a different distro package and support aarch64?

Change the libutil-linux dependency to util-linux-libs

python36 is EOL since 2021 and will likely be deleted from AUR in the near future.

Just tried the latest PKGBUILD for the 5.7.3 release [57f67ecfd981], and it looks like the download link is broken. Here's the diff to make it work:

diff --git a/PKGBUILD b/PKGBUILD
index 6392fe8..f961fff 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -15,7 +15,7 @@ optdepends=('python36: required for REPL')
 options=('!strip')
 provides=('swift-language')
 replaces=('swift-language-bin')
-source=("https://swift.org/builds/swift-$pkgver-release/centos7/swift-$pkgver-RELEASE/swift-$pkgver-RELEASE-centos7.tar.gz")
+source=("https://download.swift.org/swift-$pkgver-release/centos7/swift-$pkgver-RELEASE/swift-$pkgver-RELEASE-centos7.tar.gz")
 sha256sums=('10138dce4306309fdd77c530a7c19e4d00586cdaf5698dd7412004bcb6d86d28')

 package() {