I'm getting errors trying to build swiftc. I don't have Swift installed because I was told long ago you can't build Swift if Swift is installed. Does this make sense? I'm running Debian 12 64-bit x86.
==== /home/swift/swift-source/swift/stdlib/public/Concurrency/PartialAsyncTask.swift:207:30 ====
123 | @available(SwiftStdlib 5.9, *)
124 | @available(*, deprecated, renamed: "ExecutorJob")
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
125 | @frozen
...
206 |
207 | public init(_ job: __owned Job) {
| ^ warning: 'Job' is deprecated: renamed to 'ExecutorJob'
| ^ note: use 'ExecutorJob' instead [replace 'Job' with 'ExecutorJob']
208 | self.context = job.context
[1283/1501][ 85%][6588.633s] Compiling /home/swift/swift-s...ft-backtrace//LINUX/x86_64/swift_backtrace_linux_x86_64.o
FAILED: stdlib/public/libexec/swift-backtrace/LINUX/x86_64/swift_backtrace_linux_x86_64.o /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace/LINUX/x86_64/swift_backtrace_linux_x86_64.o
cd /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace && /usr/bin/cmake -E make_directory /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace/LINUX/x86_64 && /usr/bin/cmake -E env PYTHONIOENCODING=UTF8 /usr/bin/python3 /home/swift/swift-source/swift/utils/line-directive @/home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace/3d038f3e4193461e6edb609231d0293abc2bc698.txt -- /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/./bin/swiftc -c -sdk / -target x86_64-unknown-linux-gnu -resource-dir /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/./lib/swift -O -D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY -D SWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED -D SWIFT_ENABLE_EXPERIMENTAL_DIFFERENTIABLE_PROGRAMMING -D SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING -D SWIFT_ENABLE_EXPERIMENTAL_OBSERVATION -D SWIFT_RUNTIME_OS_VERSIONING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -D SWIFT_STDLIB_ENABLE_VECTOR_TYPES -D SWIFT_STDLIB_HAS_COMMANDLINE -D SWIFT_STDLIB_HAS_STDIN -D SWIFT_STDLIB_HAS_ENVIRON -Xcc -DSWIFT_STDLIB_HAS_ENVIRON -D SWIFT_THREADING_LINUX -tools-directory /home/swift/swift-source/build/buildbot_linux/llvm-linux-x86_64/./bin -module-cache-path /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/./module-cache -no-link-objc-runtime -D SWIFT_ENABLE_REFLECTION -module-name swift_backtrace_linux_x86_64 -Xfrontend -disable-objc-interop -I/home/swift/swift-source/swift/stdlib/public/Backtracing/modules -Xcc -I/home/swift/swift-source/swift/include -Xcc -I/home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/include -parse-as-library -Xfrontend -disable-implicit-concurrency-module-import -Xfrontend -disable-implicit-string-processing-module-import -Xcc -fno-omit-frame-pointer -whole-module-optimization -color-diagnostics -resource-dir /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/./lib/swift -I /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/./lib/swift/linux -o /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace//LINUX/x86_64/swift_backtrace_linux_x86_64.o @/home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/stdlib/public/libexec/swift-backtrace/3d038f3e4193461e6edb609231d0293abc2bc698.txt
/home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/bin/swiftc: error while loading shared libraries: libswiftCore.so: cannot open shared object file: No such file or directory
[1284/1501][ 85%][6615.105s] Compiling /home/swift/swift-s...ift-linux-x86_64/stdlib/public/core//LINUX/x86_64/Swift.o
==== /home/swift/swift-source/swift/stdlib/public/core/Diffing.swift:352:31 ====
227 | @available(SwiftStdlib 5.1, *)
228 | private func _myers<C,D>(
| ^ note: 'C' previously declared here
229 | from old: C, to new: D,
...
351 | */
352 | func _withContiguousStorage<C: Collection, R>(
| ^ warning: generic parameter 'C' shadows generic parameter from outer scope with the same name; this is an error in Swift 6
353 | for values: C,
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Decodable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Encodable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Hashable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
ninja: build stopped: subcommand failed.
ERROR: command terminated with a non-zero exit status 1, aborting
ERROR: command terminated with a non-zero exit status 1, aborting
What command are you using to build the compiler? It is difficult to know what's going wrong if we don't know how you are building it. This looks like it might be a race where things are being built in the wrong order, because of some missing dependency.
As I noted in your other thread about 5.10, a prebuilt Swift compiler is required since 5.9 if you want the new macro features and swift-syntax parser.
How can I disable the macro and syntax parser during the build? I generally don't trust a language that can only be compiled using a prebuilt compiler of the same language. That practice allows for backdoors.
I'm using this: swift/utils/build-script -j2 --preset=buildbot_linux,no_test install_destdir=~/swift-install installable_package=~/swift.tar.gz
Pass the --skip-early-swiftsyntax flag to build-script, that will no longer require a prebuilt Swift compiler.
I'd like to know what toy languages you use then, as practically every major language like C, C++, Rust, Zig, Haskell, etc that has a self-hosting compiler requires this.
What makes you think it doesn't exist? If you run ./swift/utils/build-script --help | grep skip-early-swiftsyntax -A1, it is clearly there, as it was added in late 2022, long before 5.9 branched. If you're unable to run it with the preset, try modifying that preset itself in swift/utils/build-presets.ini.
I'm wondering if anyone has used it, because I get a syntax error trying to do so.
It seems that the script itself is buggy because the error is nonsensical.
I've tried many combinations e.g.
--skip-early-swiftsyntax by itself
--skip-early-swiftsyntax=true
--skip-early-swiftsyntax true
--skip-early-swiftsyntax TRUE
etc.
Take a look at the help, I now see that presets cannot be modified from the command-line:
> ./swift/utils/build-script --help | grep "Preset mode" -A7
Preset mode in build-script
---------------------------
All buildbots and automated environments use 'build-script' in *preset mode*.
In preset mode, the command line only specifies the preset name and allows
limited customization (extra output paths). The actual options come from
the selected preset in 'utils/build-presets.ini'. For example, to build like
the incremental buildbot, run:
So you cannot modify the preset from the command-line, only from the configuration file, which I listed for you earlier.
OK, I added the skip-early-swiftsyntax flag to the presets. Should I also remove any contrary presets like swiftsyntax and install-swiftsyntax?
Here's the latest build error:
/home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/bin/swiftc: error while loading shared libraries: libswiftCore.so: cannot open shared object file: No such file or directory
[1284/1501][ 85%][6331.335s] Compiling /home/swift/swift-s...ift-linux-x86_64/stdlib/public/core//LINUX/x86_64/Swift.o
==== /home/swift/swift-source/swift/stdlib/public/core/Diffing.swift:352:31 ====
227 | @available(SwiftStdlib 5.1, *)
228 | private func _myers<C,D>(
| ^ note: 'C' previously declared here
229 | from old: C, to new: D,
...
351 | */
352 | func _withContiguousStorage<C: Collection, R>(
| ^ warning: generic parameter 'C' shadows generic parameter from outer scope with the same name; this is an error in Swift 6
353 | for values: C,
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Decodable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Encodable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
=== /home/swift/swift-source/swift/stdlib/public/core/SIMDVector.swift:63:17 ===
62 | /// A type that can be used as an element in a SIMD vector.
63 | public protocol SIMDScalar {
| ^ warning: protocol 'SIMDScalar' should be declared to refine 'Hashable' due to a same-type constraint on 'Self'
64 | associatedtype SIMDMaskScalar: SIMDScalar & FixedWidthInteger & SignedInteger
ninja: build stopped: subcommand failed.
ERROR: command terminated with a non-zero exit status 1, aborting
No, those are separate and irrelevant to the compiler. early-swiftsyntax is what you need a prebuilt Swift compiler for- it builds a swift-syntax parser first that can be linked into the freshly-built Swift compiler- the others are built with the freshly-built Swift compiler at the end.
Hmm, same as before. Try checking the runpath for your freshly-built compiler and see if it references the right directory with the stdlib, something like this:
That means it is looking for the stdlib in /home/swift/swift-source/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux/. If you don't see it there, something is going wrong with the build, so check that runpath and that directory first.
Also, check your CMake log and make sure the bootstrapping mode is set to bootstrap:
I got it to compile without the patch. The key was to put the 'skip-early-swiftsyntax' option in the right part of build-presets.ini, up near the top of the file in the Linux section.
No, that has nothing to do with this problem. The issue is that the compiler has a dependency on the Swift stdlib, so that has to be built first. Without that patch, ninja may or may not schedule building the stdlib first, so sometimes it will work, just like with race conditions. With the patch, you ensure the stdlib is always built first, so the build always works.
So, if a hacker manages to modify that prebuilt compiler (or someone coerced by a government does) to add malware that builds future compilers with the same malware, is that not a problem in your opinion?
Which "prebuilt compiler?" There are several, most built purely from source. Also, you can still build the current 5.9 release and previous Swift compilers from source yourself, then use that to build a 5.10 or 5.11 compiler that eventually requires a prebuilt Swift compiler.
Considering most code today- whether C, C++, Rust, or most languages- is built by prebuilt compilers written in the same language, I'd like to know what software you're using that doesn't have this potential problem.
C/C++ is not a perfect example, as there are multiple popular compiler implementations, which limits the attractiveness of those languages as attack targets. for a language like swift which only has one compiler implementation, and which depends heavily on one corporate CI system to compile the toolchains, it is hard to imagine how one could respond to such an attack even after it became known.
I made a similar point about the multiple prebuilt OSS Swift compilers available from the linked distro and other packaging systems.
The single compiler implementation only matters for open source insertion attacks: I'm skeptical anyone could get that in, but I'm certainly no expert. Given the many linux and macOS builds I linked yesterday, the "one corporate CI system" is only true of Xcode, but given how much money they have to throw at securing those builds and the massive reputational damage at stake, I doubt such binary build insertions will happen.
I'm not saying this isn't a concern for a language without more implementation and distribution diversity like Swift, but it is fairly unlikely.